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Foreword 


The American Radio Relay League takes pride in publishing papers for this Eighth 
ARRL Amateur Radio Computer Networking Conference. 


These papers tell the continuing story of the evolution of amateur packet radio and 
AMTOR. Prominent this year are numerous papers on TCP/IP and ROSE 
networking. 


Not particularly evident from these papers are several projects being undertaken by 
the ARRL Committee on Amateur Radio Digital Communication, namely: (a) 
development of more-robust HF modems and protocols, (b) work with the ARRL 
Membership Services Committee for revision of FCC Part 97 rules pertaining to data 
and RTTY communication, and (c) later versions of AX.25. 


As in previous conferences, all papers in these proceedings are unedited and solely 
the work of the authors. 


David Sumner, K1ZZ 
Executive Vice President 


Newington, Connecticut 
September, 1989 
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2. The Big Picture 


Before defining any broadcast protocol one must understand the operational needs and the operating 
environment(s) where it will be used. The table below shows three typical operating environments 
found in packet networks and their associated characteristics. This includes the identification of the 
technology used to distribute the information to each user, the number of simultaneous users, the link 
technology used to transport the data, and the recovery mechanism. Based on this information 
conclusions were made about the relative manageability, overhead and reliability. From the table one 
can see that there is clear advantage to the use of a network switch as the broadcast point. The network 
switch assumes it is connected to users with personal computers in their stations, and that they are 
running the BBC! software. The BBC package provides the protocol for retransmit requests and other 
functions needed to administer broadcast distribution of files and the establishment of conferences or 
nets. Some investigation into an implementation using embedded TNC software is also underway, but 
no firm plans have yet been established. 






Broadcast Distribution Comparison 


[Pam | ee te 

cana tpl Bacco Bh -2 Type | Type | Type | 

hc FO a el a 
Similitanesuily Frames Frames : 

PBBS One per LAPB Medium Medium 

vee | eB pe 


Network Switch* Many LAPB Frames | UI Frames High 
Simultaneously _ BBC BBC 


* The definition of a "Network Switch" includes high profile packet switches and satellites. 











3. Architecture 


The previous sections have defined the user needs and operational environment. In this section we will 
describe the supported architecture and applications for which the protocol has been designed. 


In figure 1 (Broadcast Environment) there is a packet network consisting of five ROSE X.25 Packet 
Switches. This network has three local networks providing user access and one providing server access. 
The fifth switch is internal to the backbone and is transparent to all users. 


The ROSE X.25 Switch serving the ROSErvers is shown sending a network alarm contained in a level 2 
Unnumbered Information (UI) frame to one of the ROSErvers. This is an unacknowledged message and 
provides the system with the information needed to track down problems when the network manager Is 
available. The alarm type and parameters may be remotely added or deleted as shown in the top and 
bottom of figure 2. 


Three of the ROSE X.25 Switches have the BBC Broadcast application loaded in the switch. The two 
ROSE X.25 Switches in "Network Broadcast Operation" are receiving their broadcast data in real-time 
from the ROSErver, and are sending it out to their users in level 2 Unnumbered Information (UI) 
frames. To set this up, the ROSErver made a X.25 level 3 connection to the BBC Broadcast 
application in each switch, then sent control data to the ROSE X.25 Switch BBC application. This 


1. The "BBC" is a set of application software which runs on MS-DOS™ computers and ROSE X.25 Switches. The author felt 
thal no name was better known in the broadcast industry than the "BBC", and so named the system "BBC". It should be noted 
however that there is no relationship to the British Broadcasting Corporation, leaving open the possibility that the author had 
other motives for naming the system "BBC". 


control information, included the distribution group, the time of transmission (now), recovery timers and 
counters required for the broadcast. If the file is short, the ROSErver can load the control information, 
and the broadcast file into the ROSE X.25 Switch and then disconnect. The file broadcast would occur 
at the time specified without further participation from the ROSErver. The setup aspects of the 
broadcast may be set by predefined controls or through the mechanisms shown in figure 3. Figure 4 
shows the broadcast file distribution flow. The control protocol data units shown in the figures are not 
defined in this paper* and are optional at this time. See footnote 2. 


In the local network at the bottom of the figure, the group there has a net or conference in progress 
which allows any user to send data over a standard LAPB AX.25 link to the ROSE X.25 Switch BBC 
application. The BBC application then broadcasts the data using UI frames to the whole group. 
Recovery is provided for any data that is lost. See figure 6 for the event flow. The control protocol 
data units shown in the figures are not defined in this paper and are optional at this time. See footmote 2. 


4. Broadcast Protocol Data Units 


The Broadcast Protocol Data Units (BPDUs) listed below provide structure to the messages specific to 
particular applications. The five BPDU types are: 






Broadcast PDU Types 


_BPDU Type _ 


Unconfirmed data unit 


_ | User or File Data 
Create Request 












Confirmed data unit 
Control and User Stations 
Confirmed data unit { 
| Control and User Stations 
| Confirmed data unit 
_ | Control and User Stations 
Get Response | Confirmation of Get Request _ 


Unconfirmed data unit 


Control Stations — 
The Event Report PDU provides the user with an envelope for user or file data in the broadcast 
application. No specific acknowledgement is required for this data when transmitted in a UI frame, but 
it may be provided by underlying protocols such as AX.25 or X.25. 















| Create Response 
Delete Request 














| 


| Get Request 











The Create Request and Response PDUs provide the control station with the capability to establish 
broadcast Master Control Blocks which contain parameters needed to control file transfers and 
conferences, or nets. 


The Delete Request and Response PDUs provide the control station with the capability to remove 
broadcast Master Control Blocks. 


2. The control protocol data units (CREATE, DELETE, GET & SET) and associated data structures are to be defined in a later 
paper. 


The Get and Set PDUs allow a control station to read and modify control parameters contained in a 
broadcast Master Control Block. 


5. Event Report Messages 


The basic protocol data unit (PDU) in the broadcast application and in the BBC software is the Event 
Report. It is the basis for several message types which contain the broadcast and recovery data. Event 
Reports may be sent via UI frames or via connected mode packet protocols such as AX.25 and X.25. 
There are several message types based on this PDU. They all use the structure of the Event Report 
PDU to convey data specific to the application. This is the only required PDU. The message types 
based on this PDU are: 












~ | Provides Context Information 
Provides File Data 
Requests Transmission of 
_ | Files or Missing Segment(s) _| 
End Of File | Signals End of Transmission | 















Request 


Transmission 








The notation used to define data types and lengths in this document is listed in the tables below. 









Int-1 
Int-2 
Int-3 


one byte unsigned integer range 0 - 255 
two byte unsigned integer range 0 - 65,535 


three byte unsigned integer range 0 - 16,777,215 


















Integers are sent low order byte first. Printable Strings are sent left most byte first. 


5.1 File Header Message 


The File Header message type provides the context information needed to handle the file in the receiving 
user’s system. This header will be preserved by the broadcasting device for the duration of the 
broadcast session. This message is sent when a Request Transmission message is received with a 
segment number of 0. 







File Beader Message 


Pt Curent Version 
masteags tee 
eee [0 incl | esas Te 
roles | Pons [5-30 | Ua ji, pa wi 20 
“Broadeastype | Content Encoding | PS-10 | Left jusied pad with 20H 
BroadcastAlias == Taentifier range Tne eer 777,215 
BroesSine | Enomers —[ in—[ Sos Vast 
[SegmentCount | Teper 




































Field Definitions 


Version - The version number is defined for this release to have the value 0. 


Event Report - This field is defined to be inform the receiving system that this message is an event 
report PDU. 


File Header - This field is defined to inform the receiving system that this message is a file header. 
Originator - Callsign of the information source. 


Broadcast Title - Activity Name. Some consideration is being given to registering these to ensure 
uniqueness. 


BroadcastName - This is the filename of the file being sent. 
BroadcastType - Content encoding is sent in this field. Standard values are: 


ASCII Text and the control characters defined as ASCII 
BINARY Generic eight-bit data 
VOICE Generic voice traffic 


VIDEO-CCC The string "VIDEO-" followed by the ISO 3166 Alpha-3 
Code related to the video standard in use. 


BroadcastAlias - This is the short tag sent with each data segment event report in a given broadcast 
session. It is more compact than the Originator, BroadcastTitle, and BroadcastName. It should not 
be reused by a given station for long periods of less than 30 days. 


BroadcastState - This parameter informs the user of the current distribution and recovery state of 
the file. 


(0) PENDING _ - File loaded but not sending 
(1) ACTIVE - File loaded and file being sent 
(2) HEADER _ - File is being sent but only the header was stored. 


SegmentSize - This field provides the number of bytes in a segment. This value provides the 
blocking information needed to retrieve a segment. This will be quite useful when requesting fills 
from PBBS-type servers. These servers will often set up broadcasts with a variety of segment sizes 
depending on the environment. The default value is 240. 


SegmentCount - This field provides the total number of segments in the broadcast. 


5.2 Data 


The Data message type provides the information content needed to transport and correlate elements of 
the file in the receiving user’s system. This message is sent in sequence by the broadcaster and in a 
round robin fashion when a Request Transmission message is received with a matching segment number. 


Data Message _ 


a 2 Cs 
a i ee 
= ee a 2 a 


oeeenneane 


Field Definitions 
- Data - This field is defined to be inform the receiving system that this message is a data message. 


- SegmentSize - This field will match the value given in the File Header when broadcasting files. 
When broadcasting conference or net messages this value may be ignored. 





- SegmentNumber - This field provides the sequential sequence number for this segment. 


- SegmentData - This field will default to 240 bytes of user data when the packet size is defined to be 
256 octets. 


5.3 Request Transmission Message 


The Request Transmission message type provides the user with the capability to request retransmissions 
of missing segments, or the transmission of a file header or file header and file. This message is sent at 
any time by the user and causes transmissions or retransmissions to be made in a round robin fashion. 


| Request Transmission ——— 


a a AC 
et pat [0st ee 
Request Trnsniin [2 Pine [Message Type 


Session Identifier range limited 0-16 777,216 


See values below 


| [Segment 


Field Definitions 


- Request Transmission - This field is defined to inform the receiving system that this message is a 
Request Transmission message. 





- SegmentSize - This parameter conveys the segment size originally specified in the File Header. This 
field will be most useful for "after broadcast" queries to a fileserver. It provides the server with a 
stepping index which will match the SegmentSize of the original broadcast. The value of this field 


may be ignored by the receiving system when broadcasting conference or net messages. 
- BroadcastRequestType - This field tells the broadcaster what segments to send the user. Standard 
values are listed below. 


0 > Greater than the segment number specified in Segmenta. 
SegmentB is not used. 


1 <_ Less than the segment number specified in SegmentA, 
SegmentB is not used. 


2 - All between the SegmentA value and the SegmentB value. 


- SegmentA - This is the segment number used with the BroadcastRequestType field. 


- SegmentB - This is the high order segment number value field used when the BroadcastRequestT ype 
field is set to 2. 


5.4 End Of File Message 


The End Of File (EOF) message type provides the user with an indication that this message is the last 
segment in the file. When broadcasting conference or net messages, this message serves as an indication 
that the operation is closed. 


End Of File Message 
Element 






[Version PO inet | Current Version 
EventReport | O00 | Inet | PDUType 
‘EOF [3 | Inti | MessageType 
Session Identifier range limited 0-16,777,216 
| SegmentSize | Integer | Int | bytes in segment 
Reber of ta peer 


: SegmentSize number of bytes. 


User Data 
Field Definitions 


+ End Of File - This field is defined to inform the receiving system that this message is an End Of 
File message. 


























- SegmentSize - This value is the only time in a file transfer where the value can be different than the 
one given in the file header. 


5.5 Conference Header Message 


The Conference Header message type provides the context information needed to set up a conference for 
users. A conference is a similar to a roundtable type net. It operates in any way the organizer and 
participants may wish. Dialogue control is not regulated by the broadcaster but by the participants. 
This header will be preserved by the broadcasting device for the duration of the broadcast session. This 
message is sent when a Request Transmission message is received with a segment number of 0. 


The Conference Header message is structured like a File Header message but there are some changes 
designed to simplify human operation. Once established, the Conference users will use the same 
messages as is used for broadcast file operation. 













~ Conference Header Message 

Data Type | Notes 
Peston One |Current Version 
event Repo [0 inet DU Type 
[et justed, pad with 208 
Cat jusifed pad with 208 
J 
-BroadcastType | Coment Encoding | PS-10 | Left used pad with 20H | 
Session Iden 
——— a See Values below 
Nested fa ar roo — 


Field Definitions 
































+ Version - The version number is defined for this release to have the value 0. 


- Event Report - This field is defined to be inform the receiving system that this message is an event 
report PDU. 


- Conference Header - This field is defined to inform the receiving system that this message is a 
conference header. 


- Originator - Callsign of the user. 


- Broadcast Title - Conference or Net Name. Some consideration is being given to registering these 
to ensure uniqueness. 


- BroadcastName - This is the Session name for the session. 


- BroadcastType - Content encoding is sent in this field. Standard values are: 


ASCII Text and the control characters defined as ASCII 
BINARY Generic eight-bit data 
VOICE Generic voice traffic 


VIDEO-CCC The string "VIDEO-" followed by the ISO 3166 Alpha-3 
Code related to the video standard in use. 


- BroadcastAlias - This is the short 4 character tag sent with each data segment event report in a 
given conference session. It is more compact than the Originator, BroadcastTitle, and 
BroadcastName. It may be re-used as often as is deemed desirable by those managing the 
conference or net. 


- BroadcastState - This parameter informs the user of the current distribution and recovery state of 
the conference or net. 


(0) PENDING - Conference loaded but not sending 
(1) ACTIVE - Conference loaded and data being sent 
(2) HEADER - Conference data is being sent 


but only the header was stored. 


SegmentSize - This field provides the number of bytes in a segment. This value provides the 
blocking information needed to retrieve a segment. This will be quite useful when requesting fills 
from PBBS-type servers. These servers will often set up broadcasts with a variety of segment sizes 
depending on the environment. The default value is 240. 


- SegmentCount - This field provides the total number of segments in the broadcast. 


6.0 TNC Settings 


TNC settings for broadcast operation are divided into two basic groups: user and broadcaster. The user 


needs to set up the TNC as follows: 


MON 
MCON 
MCOM 
BUDLIST 
LCALLS 
USERS 
PACL 
SENDPAC 
CR 

CPAC 
PACTIME 
DWAIT 
TXD 
FRACK 


ON 

ON 

OFF 

ON 

callsign of broadcaster 
i 

QO (256) 


The broadcaster needs to set up the TNC as follows: 


MON OFF 
MCON ON 
MCOM OFF 
USERS One less than the maximum value 
PACL 0 (256) 
SENDPAC 0 

CR OFF 
CPAC ON 
PACTIME AFTER 10 
DWAIT 3 

TXD 100 
FRACK 3 


Additional parameters might be set for transparent binary operation. These vary with make and model. 


See the manual for details. 


7.0 Conclusion 


This paper has described the broadcast environment, the user applications and the protocols needed to 
make it all work. The Event Report portion of the broadcast protocol specification is outlined for those 
who might wish to experiment with this interesting area. Additional broadcast message types and the 
broadcast control protocol will be added to the specification and published in Amateur circles in the near 
future, Comments and suggestions for additions and changes would be welcome and are requested. If 
we can be of assistance with your experimentation, contact us by mail or phone. 
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Broadcast Report - Event Flow 
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Figure 2 
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Broadcast Setup Flow 
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Broadcast Flow - File Operations 
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Figure 4 
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License-Free Spread Spectrum Packet Radio 


Albert G. Broscius, N3FCT 


Distributed Systems Lab, CIS Dept. 
University of Pennsylvania 
200 S. 33rd Street 
Philadelphia, PA 19104-6389 


ABSTRACT 


Under Part 15.126 of CFR Title 47 the FCC has authorized the use of unlicensed spread 
spectrum transmitters with output power not to exceed one watt in the 902-928 MHz, 2400 
MHz, and 5800 MHz bands shared by the amateur service. Several manufacturers have already 
offered products which have been approved by the FCC for this class of operation. Although 
this is not ham technology authorized by Part 97 of the FCC Rules, it may be advantageous for 
amateurs to be aware of the use and possibilities of such equipment to augment our regulated 
packet communications. Conversely, the proliferation of unlicensed transmitters in these ama- 
teur shared bands could spell trouble for weak signal work in densely populated areas. 


Introduction 


Amateur experiments with spread spectrum techniques under an STA have provided a basis for FCC rule 
changes in 1986 allowing restricted forms of spread spectrum modulation on the amateur bands. Only frequency 
hopped (FH) and direct sequence (DS) spreading has been authorized, though, prohibiting hybrid spreading tech- 
niques which are often preferred in modern designs. The pseudo-noise (PN) code sequences available for DS are 
also restricted by the amateur rules to a set of three linear feedback shift register (LFSR) sequences. Further, 
transmitted power is restricted to one-hundred watts and a technical log of all spread spectrum activity must be 
kept. Unfortunately, work in this area has not yet yielded commercial or even kit-form amateur spread spectrum 
transceivers in spite of the fine engineering effort spent on this technique by several groups around the country. 

Deciding to bring industrial resources to bear on the technology transfer from the military to consumer elec- 
tronics, the FCC added Part 15.126 of its Rules in June, 1985 in order to speed along the development efforts 
already authorized for several amateur groups under a 1981 STA. This new section of the low-power communi- 
cation devices regulations mandates only the power distribution uniformity, the occupied bandwidth for DS 
transmitters, and the bandwidth and number of hopped channels for FH transmitters. The FCC's attitude toward 
this technology appears to foster commercial applications which are capable of taking advantage of "wasteland" 
properties used by Industrial, Scientific, and Medical (ISM) equipment for non-communication purposes and by 
high EIRP radiolocation systems [4] without undue interference to amateur transmissions on these shared bands. 
The ability of spread spectrum systems to improve signal-to-noise ratio should enable communication transceivers 
to overcome the high noise floor resulting from RF sources operating on these bands. Narrowband interference 
sources such as amateur transmissions on these shared bands would also be combatted by a properly designed 
spread spectrum system. 


Commercial Systems 


The commercial systems currently approved for operation under this Part have centered so far on data com- 
munications requirements although some wireless alarm type applications have been discussed. One system 
marketed by O’Neill Communications Inc. claims to have a channel transmission rate of 38.4 kbps and a radio- 
computer transmission rate of 9.6 kbps [1]. It also claims to use AX.25 as its communication protocol between 
radio nodes. With a transmit power of 20 milliwatts, this system states an indoor range of 100 feet and an out- 
door range in excess of 500 feet. For range extension, the manufacturer suggests the use of up to two of the radio 
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units in repeater operation. With an estimated cost of approximately $500 per node, this is one of the less expen- 
sive systems being marketed. 

The other data communication system now marketed is called ARLAN and is sold by a Canadian firm, 
Telesystems SLW of Ontario. There are two versions of ARLAN: one supports asynchronous communication 
between terminal ports of standalone radio units, the other consists of an IBM PC-type circuit board with an 
antenna connection at the rear of the card. Shipped with a stub antenna, the card uses the 902-928 MHz band to 
connect computers together using the Novell Netware protocols at 200 kbps and up to 1 watt of transmitted 
power. Interestingly, the company claims to have tested a pair of the IBM PC-type machines together with beam 
antennas successfully at a distance of six miles. The price on these units, however, is approximately $1500 per 
node which may be prohibitive for use by individuals. 


Implications for the Radio Amateur 

While it may be disheartening that commercial systems have become available before their amateur couter- 
parts, it should be mentioned that these license-free systems may be used to augment or supplement our communi- 
cations abilities even though they are not regulated under Part 97 of the Rules. It is also possible that a system 
which qualifies under 15.126 could be modified to be pursuant to Part 97 spread spectrum rules and thus allowed 
to operate at the higher power limit, one hundred watts, available for amateur spread spectrum as long as the con- 
trol operator satisfied all appropriate requirements of the Rules. And of course, placing a 15.126 unit on a 
Microsat-class vehicle [5] could pave the way for license-free space operation although there may be other res- 
trictions which come into play in that situation. 


The design of a power-limited spread spectrum network with realistic inter-node distances would require 
substantial antenna engineeering skills which could be provided by amateur operators familiar with propagation 
conditions on these bands. However, the resulting network would be free of Part 97 restrictions in the spirit of the 
pre-Commission Ham activities. Realistically, a Wild West scenario of competing BBS networks and CB-style 
chaos could make this non-Ham world an unpleasant environment. Unfortunately, unless a pro-active position on 
this technology is taken, we may see a digital CB world forming around our shared allocations. 


Neglecting intentional interference to amateur transmissions and power-limit abuses, there is still the issue 
of a high noise floor on the weak signal portions of the shared bands. Although these bands now suffer from their 
shared status, some feel that an influx of consumer electronics items which may each transmit up to one watt will 
cause unacceptable degradation on the "quiet regions" of the band plan. Considering the possible density to be 
tens of radiators per city block, the argument of RF pollution seems credible. 


Recommendations 


To responsibly address this technology, we feel amateur operators should experiment with the commercial 
systems now available in establishing long distance communication paths using high-gain antenna systems cou- 
pled with the maximum legal power of one watt, determining interference levels seen by weak signal receivers 
attributable to spread spectrum transmissions, and carefully introducing this technology to computer bulletin 
board operators who cculd financially support development of an unlicensed computer internet. 
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Appendix: 


Code of Federal Regulations Title 47: Part 15.126 Operation of spread spectrum systems. 


Spread spectrum systems may be operated in the 902-928 MHz, 2400-2483.5 MHz, and 5725-5850 MHz 
frequency bands subject to the following conditions: 

(a) They may transmit within these bands with a maximum peak output power of 1 watt. 

(b) RF output power outside these bands over any 100 kHz bandwidth must be 20 dB below that in any 100 
kHz bandwidth within the band which contains the highest level of the desired power. The range of frequency 
measurements shall extend from the lowest frequency generated in the device (or 1OOMHz whichever is lower) up 
to a frequency which is 5 times the center frequency of the band in which the device is operating. 

(c) They will be operated on a noninterference basis to any other operations which are authorized the use of 
these bands under other Parts of the Rules. They must not cause harmful interference to these operations and must 
accept any interference which these systems may cause to their own operations. 

NOTE: Spread spectrum systems using the 902-928 MHz, 2400-2500 MHz and 5725-5850 MHz bands 
should be cautioned that they are sharing these bands on a noninterference basis with systems supporting critical 
government requirements that been allocated the usage of these bands on a primary basis. Many of these systems 
are airborne radiolocation systems that emit a high EIRP which can cause harmful interference to other users. For 
further information about these systems, write to: Director, Office of Plans and Policy, U.S. Department of Com- 
merce, National Telecommunications and Information Administration, Room 4096, Washington, D.C. 20230. 

Also, future investigations of the effect of spread spectrum interference to Government operations in the 
902-928 MHz band may require a future decrease in the power limits. 


(d) For frequency hopping systems, at least 75 hopping frequencies, separated by at least 25 kHz, shall be 
used, and the average time of occupancy on any frequency shall not be greater than four-tenths of one second 
within a 30-second period. The maximum bandwidth of the hopping channel is 25 kHz. For direct sequence sys- 
tems, the 6 dB bandwidth must be at least 500 kHz. 

(e) If the device is to be operated from public utility lines, the potential of the RF signal fed back into the 
power lines shall not exceed 250 microvolts at any frequency between 450 kHz and 30 MHz. 

[SO FR 25239, June 18, 1985] 
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ABSTRACT 


High-Speed networking is qualitatively different from the 1200 baud omnidirec- 


tional multicasting now in widespread use. 


A true network of high-speed nodes 


require planning, and (at least from the Amateur perspective) unusual networking 
architectures to take advantage of the much higher speeds. Fundamental limitations 
on network parameters must be understood, and parameters must be coordinated for 
consistent operation within the network. The potential applications possible with truly 
high-speed networks are also qualitatively different from what is provided by slower 
networks, offering a tremendously exciting future for amateur radio as a whole. 


1. What is High Speed? 


Because of the predominance of 1200 
baud half-duplex AFSK multicasting as the 
defacto standard for packet radio networking, it 
is easy to look at moderate increases in tran- 
sport speed (to 9600 baud, or even 56 kilobaud) 
and be excited about the relatively ‘“‘high 
speed’ operation that such modems _ allow. 
However, from an applications standpoint, such 
improvements allow us to do the same things 
we've always done, albeit a little faster, but do 
not open the door to many applications that 
require real “‘high speed’’ networking. 


High speed in this context means 250 
kilobits/sec to 10 megabits/sec and above. We 
are intentionally excluding the WA4DSY 56 
kilobits/sec modem because with that modem it 
is still possible to use ‘‘standard’’ networking, 
that is, uncoordinated stations, omni antennas, 
and CSMA. Because of this, the WA4DSY 
modems are expected to play an important part 
in networking systems of the future, especially 
as feeders to high speed networks (local access 
channels). But for the purposes of this discus- 
sion, we'll consider 56kb as the upper limit of 
the “‘low speed” packet technology. 


2. Network Architecture and Software Impli- 
cations 

The low capacity of the existing 1200 baud 
AX.25 network has restricted users to the most 
undemanding of applications: manual keyboard- 
to-keyboard chatting, the transfer of small text 
files, store-and-forward electronic mail, and DX 
spotting. But as fast digital links become avail- 
able, much more powerful forms of computer 
networking will become practical. This requires 
higher level protocols above AX.25. 

The ARPA Internet protocols, commonly 
known as ““TCP/IP’’, are clearly the leading 
contender for a high speed amateur network. 
Over the past decade, the Internet protocol suite 
has matured in a diverse academic, military, 
research, and commercial setting. For several 
years, TCP/IP implementations have been in 
everyday use on hundreds of thousands of com- 
puters ranging from laptop PCs to desktop 
workstations to Cray supercomputers. Ether- 
nets, twisted pairs, token rings, fiber optic chan- 
nels, satellite links — and amateur packet radio 
channels, among other things, are regularly 
used to carry IP datagrams. TCP/IP has 
become the method of choice for providing 
Standard network services across a wide variely 
of computer systems and local and wide-area 
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networking technologies. In amateur packet 
radio, TCP/IP has been growing steadily in 
popularity since the introduction of the KA9Q 
Internet Protocol software package. We believe 
that the ARPA Internet is an excellent role 
mode! for the kind of network we can build as 
amateurs, and that we can learn a great deal 
From the Internet experience. 


Most recently the original ARPANET 
packet switched network, operating since the 
early 1970s with 56 kb/s links, has given way to 
a new IP-based national backbone network, the 
NSFNet, plus thirteen regional networks. Virtu- 
ally every link in this new Internet operates at 
the North American T-1 rate, 1.536 Mb/s. This 
brings the Internet into the ‘“‘high speed” 
calegory as we've defined it in this paper. 

The rapid growth in size and capacity of 
the Internet has caused some growing pains. 
The original routing algorithms proved inade- 
quate; new ones have been developed and are 
now coming into use. A lot of work is going 
into the study of congestion in large datagram 
networks like the Internet. This work is now 
paying off with a set of recommended conges- 
tion avoidance algorithms for both the transport 
protocol (e.g., TCP) in the end system and in 
the interior packet switches (IP routers). The 
TCP algorithms in particular have also proven 
themselves in the slow speed amateur packet 
radio environment. 


““Network management’’ is a hot topic. 
Operators need to know quickly when links or 
routers fail, and they need to monitor traffic 
patterns in order to plan the most effective allo- 
cation of additional resources. Of course, the 
network should take care of itself as much as 
possible. 

One might think that with a three or four 
order-of-magnitude increase in link speed (e.g., 
from 1200 b/s to 1-10 Mb/s) that our perfor- 
mance problems would disappear forever. This 
is not necessarily true! Although excess capacity 
is certainly an effective short term antidote to 
congestion, the Internet’s experience has been 
that network demand is gaseous — it eventually 
expands to fill the available capacity! Although 
some of this growth will come from new users 
and from increased use of traditional services 
like email and file transfer, the real kick will 
come from qualitatively new applications like 
digital voice and image transmission that high 
speed networking will make practical for the 


first time. 


But even for the more traditional com- 
puter networking applications there will be chal- 
lenges. For example, when the NSFNet 
replaced the ARPANET, the  ‘“‘delay- 
bandwidth’? product of the Internet backbone 
went up by a factor of 27. No matter how large 
the link bandwidth gets, the speed of light 
remains the same. Also, the more packet 
switches there are in a path, the greater the total 
“store and forward’’ delay. For example, the 
distance between New York and San Francisco 
is 4139 km. The one-way speed-of-light delay is 
therefore about 13.8 ms. If a terrestrial 
microwave route were set up in a straight line 
between these two cities with 50 km repeater 
spacing, 84 hops would be required. If the 
repeaters are in fact packet switches, and if the 
links all operate at | Mb/s, then the accumu- 
lated store-and-forward delay for a 200 byte 
packet sent across this path would be 132.8 ms, 
almost ten times the speed-of-light delay. (The 
actual value would be larger, since we've 
ignored the processing delay of the packet 
switch software.) 


One technique for reducing store-and- 
forward delay is “‘cut-though’’. A packet switch 
could make a routing decision and _ begin 
retransmission of a packet immediately after 
receiving its destination address — it need not 
wait for the packet to be completely received. 
One problem with cut-through is that a packet 
might be relayed before it is discovered to con- 
tain an error. One partial fix is to compute a 
separate “header checksum’’, placing it in the 
header itself so that the packet switch need only 
wait for the end of the header before making a 
reliable cut-through routing decision. Any errors 
in the data field would still be undetected, so 
they would have to be dealt with by end-to-end 
checks in the transport protocol. IP is a net- 
work protocol with a header checksum, and 
TCP is a transport protocol with end-to-end data 
checksums, so they are amenable to this tech- 
nique. 

It is quite likely, however, that in the near 
term the most practical way to handle delay- 
sensitive services like digital voice will be con- 
ventional circuit switching. This is standard 
telephone company practice, and the technology 
is very well understood. Digital circuit switches 
operating at the data rates considered here are 
now within the technical and financial capabili- 
ties of amateurs; DSP chips in particular are 


ideally suited for the task. A packet switching 
network intended mainly for computer network- 
ing could then be built on top of dedicated cir- 
cuits, with additional circuits added or removed 
as needed. The NSFNet is built in just this way; 
MCI, their long-haul carrier, is providing them 
with the ability to reconfigure their links as 
traffic patterns warrant. 

Returning to packet-switched computer 
networking, propagation delay is an important 
protocol design factor. Most protocols deal with 
it by keeping multiple packets in flight when- 
ever possible. The usual method, ‘‘sliding win- 
dows’, is used by nearly every transport (e.g., 
TCP and ISO TP-4) and pseudo-transport (e.g., 
X.25) protocol. But sliding window protocols 
cannot transfer more than one window's worth 
of data per round trip propagation time, no 
matter how large the path bandwidth may be. 
You can improve performance by enlarging the 
window, but only by using additional buffer 
memory and by increasing the performance 
‘hit’? incurred by lost packets. In our NY/SF 
example, the window would have to be at least 
84 packets in order to utilize the path’s full 
bandwidth, even if we ignore the round trip 
speed of light delay and the store-and-forward 
delays incurred by the returning acknowledge- 
ment packets. 


Another problem that needs a solution is 
efficient broadcasting. This is something that 
comes almost free with omnidirectional packet 
radio, even though we don’t currently take 
advantage of it. But the use of directional point 
to point links will require us to come up with 
other methods. 


One possibility is the ‘“‘flood’’ algorithm 
used in USENET. Each multicast packet (broad- 
casting is just a special case of multicasting) is 
sent over each link exactly once. Each node 
keeps a list of the packet IDs it has seen 
recently so it can ignore duplicates. Different 
multicast addresses could correspond to certain 
regions of the network, so that data of local 
interest wouldn’t have to cover the whole net- 
work. 


As you can see by now, the availability of 
high speed links requires parallel developments 
in digital switching hardware, protocol design 
and software if we are to use them to full 
advantage. 


3. Hardware Implications 


In order to build high-speed networks and 
to develop the software meant to run on them, 
we need the appropriate hardware. What we 
need are high-speed modems and digital inter- 
face cards capable of handling these speeds. 
Fortunately, such hardware is now appearing. 

Last year, one of us (Mike) described the 
“Totally Awesome” I/O card, for use as a 
plug-in for IBM PC/AT/386 machines. This 
card will shortly be commercially available. In 
addition, a version for the Macintosh Plus, 
Macintosh SE, Macintosh Portable, and the 
Macintosh II/IIx/IIcx/IIci will be available, 
using AppleTalk at 230.4 kilobits/second. 

Briefly, this “‘Awesome I/O card’ for the 
IBM PC/AT/386 machines features a V40 pro- 
cessor (code compatible with the 80x86 
microprocessor family), at least two Zilog 85C30 
Serial Communications Controller chips, yield- 
ing four full-duplex channels. The board can be 
expanded up to a total of six 85C30s, for a max- 
imum of twelve full-duplex channels!. It comes 
standard with 256k bytes of DRAM, expandable 
up to 512k bytes. Also, two JEDEC-standard 
EPROM/ROM sockets are included, allowing up 
to 512k bytes of EPROM when using two 256k 
x 8 EPROMs. A watchdog timer, a time of day 
clock, a programmable interval timer, and 50 
bytes of battery-backed static RAM are provided 
by a Dallas Semiconductor DS-1286 chip. Com- 
munication with the XT/AT/386 is accom- 
plished by a memory window into the XT, 
which can be either 8K, 16k, 32k, or 64k bytes 
long’. A 20-character by 2 line LCD display 
provides operator interface. 


One of the 8530s is totally DMA-driven. 
The V40 provides four DMA channels, and 
these four channels provide DMA on transmit 
and receive for both channels of one of the 
8530s, allowing two full-duplex channels to 
operate with minimal processor intervention. 
The other 85C30s are interrupt driven. The 
DMA-driven channels are fully capable of 
somewhat greater than 1.5 megabits/second. 
The other interrupt-driven channels can operate 
full-duplex at 9600 bauds or slower when the 
two high-speed channels are used. 


| On the Macintosh version, one of the channels is 
dedicated to AppleTalk. 

? That is, some of the Awesome I/O's memory is 
mapped into the XT/AT/386 address space 
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We expect the Awesome I/O card to 
dovetail nicely with the PS-186, which is now 
becoming available. One of us (Bdale) is port- 
ing the KA9Q TCP/IP package to the PS-186, 
with conditional compilation directives so that 
the same code can be run on the PS-186 or the 
Awesome I/O card. Another of us (Kevin) is 
preparing a standard driver software interface 
for the KA9Q TCP/IP package. 

Concurrently with this development, 
another of us (Glenn) is producing the high- 
speed modems we will need. Development 
work and prototyping is presently going on to 
produce a very inexpensive 1OW 900 MHz digi- 
tal radio capable of 250 to 500 kilobit/second 
operation. This radio requires approximately a 2 
MHz channel width and thus several clusters 
using such hardware can coexist in a metropoli- 
tan area without the individual cluster size 
becoming too large or congested. The radios 
are being built use Japanese 903 MHz personal 
radio band transmitter power train hardware and 
an Motorola MC13055 single chip wide band 
FSK receiver IC. A similar 20W radio for the 
1200 MHz band is also being developed since 
the 900 MHz band is not available to amateurs 
worldwide. 


4. Networking Architecture Implications For 
Higher Speeds 


One of the biggest problems inhibiting 
throughput even in our current slow-speed net- 
works is collisions. Phil Karn discussed a possi- 
ble way to avoid this problem[1]. 


In a high-speed network, however, addi- 
tional constraints suggest to us that a Token Bus 
style of topology would be most appropriate. 
See Figure |. 


Using this technique, and using half- 
duplex modems, we can guarantee that no colli- 
sions occur. Within each of the cells, there is 
one token, which is being passed continuously 
by the individual stations in the cell. This hap- 
pens even if a station has no traffic to offer the 
network; the station is responsible for repeating 
the token whenever it arrives at that station. 
When a Station has some traffic to offer the net- 
work, that station listens until it sees a “‘free”’ 
token, and changes it into a packet containing 
the information that needs to be transmitted. At 
the nexus stations, traffic can flow between local 
cells. 
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Present day packet radio time multiplexing 
methods for the physical media result in lower 
and lower throughput rates on busier channels. 
This results From collisions, retries from colll- 
sions, and back-off delays. The result of colli- 
sions is more traffic, producing more collisions, 
further driving down throughput. A 1200 BPS 
channel can quickly drop to 100 BPS actual 
throughput, even < 1 BPS in some cases. 


Soon much of the benefit of higher speeds 
is lost in collisions, retries and back-off delays. 


For higher speeds that are not point to 
point, a different time multiplexing protocol 
should be used...token passing. A frame format 
is designed to be THE token frame. It is sent 
from station to station, around a logical ring. 
The rule is simple: only the station holding the 
token frame can transmit or elicit another sta- 
tion to transmit a frame. When the token 
frame holder station is finished, it transmits the 
token frame to the next station in the logical 
ring. 


Using token passing, a station knows no 
collision can happen. Even more benefit can be 
gained by putting the link control in Virtual Cir- 
cuit mode and getting an immediate response 
from the destination station. Again, no colli- 
sion can happen to the acknowledgement. The 
source station can retry immediately if no 
response is heard, without fear of collisions. 


Present standard token passing protocols 
(IEEE 802.4, 802.5) assume no_ hidden 
transmitters. This clearly will never be the case 
in amateur radio. Work on a change to existing 
protocols is proceeding. These protocols are 
needed to take care of the case where the token 
is lost or dropped, without assuming any station 
is a master. 


Link level framing exists between stations 
that can all be reached directly by RF. Traffic at 
this level would include all applications which 
have a response time need, very close to the 
speed of the physical media. This would 
include applications such as real time. It would 
NOT include file transfers, keyboard conversa- 
tions, BBS and mail reading, and remote 
repeater controls. It might extend to digitized 
voice, bul not necessarily. 


Connection between sites which cannot be 
reached directly via RF will require repeating or 
routing. Routing involves computerized equip- 
ment that implements a protocol allowing the 
equipment to select the most efficient path to 


Token Bus 
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send frames on to their destination. Hence, 
routing connects two or more physical media 
that can't be directly connected. 


Considerable research is available on 
Token Bus, and particularly Packet Token 
Bus[2]. We intend to bring this research to 


Amateur Radio. 


5. Application Implications 


In the amateur community, one of the 
biggest hurdles to be overcome is the mindset 
of lower speed communications and current 
applications. While current AX.25 operation is 
well known, it does not offer a good beginning 
for envisioning and understanding a high speed 
network. In fact, the concept of high speed 
end-to-end data and the associated applications 
possibilities probably has no counterpart in our 
current amateur experience. Consequently, 
developing a widespread vision for such a net- 
work and coordinating its development will 
require a great deal of cooperation and wide- 
area coordination. 

A high speed network no longer need be 
thought of as a ‘“‘computer thing”. Since virtu- 
ally any signal which can be transmitted by ana- 
log means may also be transmitted digitally all 
of the diverse amateur modes presently in use 
may be supported on a network if sufficient 
speed is available. And because a network Is 
not confined to communications over a single 
span which a single transceiver pair might 
operate but rather over the entire nation or the 
world many new social and technological appli- 
cations become possible. These applications do 
not need to replace current exciting aspects to 
the hobby but rather can enhance them. DXers 
who enjoy the thrill of working another new one 
may find that a nationwide realtime spotting 
network, propagation and QSL server greatly 
enhances DXing. Similarly, chess players might 
find a chess ‘“‘news group and worldwide com- 
petition’’ exciting. Mobilers and ragchewers 
might keep in touch with others in their group 
whether they are in one locality or spread across 
the nation. The possibilities are endless! 

But let us offer several concrete examples, 
things that we intend to do once high-speed 
hardware is in place. 


5.1. Digital Voice 


This is perhaps the most obvious of the 
applications. Consider that if we sample speech 
at 7 kHz, allowing for frequencies up to 3.5 kHz 
to be present in our speech bandpass, and say 
that we require 8 bits to represent a companded 
sample, then we will require a 56 kilobit/second 
channel. With Time Division Multiplexing, we 
can slice up our 250 kilobit/second Token Bus 
network into about four voice channels. Admit- 
tedly, at the low end of the “‘high-speed’’ range, 
we cannot provide huge numbers of high-quality 
voice channels?. But, it will provide a viable 
testing ground for digital voice techniques, and 
help us build the experience to exploit the even 
higher speeds that will soon be available. 


We should point out that there is 
significant research happening in packet voice 
technologies[3-5]. We will leverage off of that 
research. We are particularly interested in two 
technologies: Full-duplex voice comrmunica- 
tions, and packet switched conferencing. 


We have a concept for a Digital HT. See 
Figure 2. 


5.2. Video 


Perhaps the most exciting new application 
made reasonable by high-speed networks is digi- 
tal video[6-8]. Consider a garden-variety bit- 
mapped screen attached to an IBM PC/AT/386, 
consisting of a 720 x 384 bit image (Hercules 
Graphics resolution). This is about 250 kilobits 
of information, uncompressed. Even so, this 
proposed high-speed network will enable such 
an image to be transmitted in about one 
second(!). Of course, higher resolution and 
color images will take longer to transmit¢. 


At these speeds, even limited animation 
becomes possible. But perhaps its biggest use 
would be in emergency applications, where we 
can survey the situation, scan in an image using 
one of the inexpensive hand-held scanners, and 
then transmit that image to a central command 
Station. 


3 Although some experiments with sophisticated 
coding schemes achieve high-quality voice with as little 
as 9600 bits/second, which would yield about 25 voice 
channels on our 250 kilobit/second links 
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So» FAX 


FAX 1s really an extension of Video. The 
differences are that paper images are usually the 
source, and that several compression schemes 
can be used[9]. Digital FAX transmission over 
packet radio could be a substantial asset for 
public service and emergency response activi- 
lies, 


5.4. Remote File Systems 


When data can be transmitted between 
stations at speeds approaching the speed of data 
transfer to and from a local hard disk, the idea 
of remote file systems becomes practical. Here, 
it would be possible for one station to ‘‘mount”’ 
a file system from a remote siation onto his 
local machine. From that point, he could then 
access the remote Station’s files as if they were 
local. In the commercial world, Sun worksta- 
tions often come diskless, and use Ethernet and 
a remote file server for data storage. Not only 
does this make it very easy to share files, it also 
allows one to use storage resources of other sta- 
tions transparently. For example, if KA9Q has 
enough disk space for the complete amateur 
callbook information, then others can access his 
database in a transparent manner. 


6. Even higher speeds 


As we Slart requiring higher speed data 
throughput we find ourselves needing to make 
much better use of our resources. At the physi- 
cal laver we must use hardware which provides 
such communication efficiently and at low cost. 
To do this, we must use techniques which get as 


4+ But not prohibitively so: a 640 x 480 x 8 bit im- 
age, such aS can be displayed on the color screen of a 
Macintosh Tl is about 2.5 megabits; it will take only 
ubout 10 seconds to transmit — uncompressed, For 
640 x 480 x 24 bits x 30 frames/second (full motion, 
full color). we need almost 222 megabits/second un- 
compressed: however, recent compression techniques 
cin achieve a [0 times reduction in required transmis- 
sion bandwidth in real time. Offline compression has 
vVielded wu 50 times compression, to require about 4.5 
megabits/second. This is within the range of speeds of 
our current 10 GHz hardware. We are eager to see the 
day when our microwave links will handle 100 
megabits/second, the standard FDDI (Fiber Optic) 
speed, and we will be able to handle several full mo- 
tion, full color transmissions at the same time. We 
who note that commercial products exist today to 
transfer | gigabit/second over fiber optic links: to 
uchieve these speeds economically via RF links will no 
doubt be an intersting problem to solve, 


much of the original transmitter power to the 
receiver so that maximum path lengths and 
Carrier/Noise ratios may be obtained. Solutions 
which waste transmit power by sending it else- 
where are wasteful, In this light, omnidirec- 
tional broadcasting on network backbones must 
be limited and eventually avoided per se. This 
is why we have suggested the Token Bus archi- 
tecture, as directional antennas can and should 
be employed, 

High speed data also will require higher 
bandwidths. To a limited degree, data rate can 
be traded for signal/noise by appropriate selec- 
tion of modulation techniques but this can pro- 
vide perhaps only a few orders of magnitude of 
date rate increase and any further increase 
requires increased signal bandwidth. 

Fortunately the above two requirements 
for high speed data communications, directed 
transmitter power and wider bandwidths are 
compatible with the same amateur resource: the 
amateur microwave and millimeter bands. The 
same scaling of wavelength which allows physi- 
cally realizable antennas to have high directivity 
and gain also occurs at portions of our allotted 
spectrum which have wide bandwidth, 


In spite of widely held misconceptions thal 
the microwave bands are expensive and difficult 
to use and only good for short range communi- 
cations, these bands represent the most cost 
effective region in which way to exchange high 
speed data, in spite of the increased cost of gen- 
erating moderate transmitter powers at these 
higher frequencies. 


The ability to use low transmitter powers 
by effectively focusing all the energy in the 
direction of the receiver also offers the oppor- 
tunity of frequency reuse within a local area. 
The current congestion on broadcast VHF 
packet 1s the antithesis of this. Rather than 
requiring high power and experiencing 
decreased C/N due to collisions with other 
omnidirectional transmitters, very small and 
inexpensive transceivers can reliably provide 
high C/N over moderate distances. At the 
same time interference-free operation of other 
links reusing the same channel which cross the 
physical path are made possible due to the 
highly directed beams. 


As we go to increasingly higher speeds, 
hardware to switch packets over a network of 
these point-to-point links must be incorporated. 
To avoid collisions (QRM) and unjust sharing 


of the spectrum resource users will need to go 
to point-to-point rather than omnidirectional 
hardware. This will be an economic issue too 
since high antenna gain will be necessary to pro- 
vide sufficient C/N for these wider bandwidth 
channels. In the interim, small local groups or 
‘“cells’’ of amateurs operating CSMA_ with 
omnidirectional antennas, and provided with a 
common path to a network switch, will be use- 
ful. For physical reasons, as well as the current 
slate of technology, it is likely that these 
moderate power broadcast ‘‘user radios’’ will 
operate in the higher VHF and UHF bands. 
Below this range there is insufficient spectrum, 
and above the higher powers needed for use 
with omnidirectional antennas is presently too 
costly. 


Through perhaps 1200 MHz, omnidirec- 
tional antennas with reasonable physical capture 
area are available. In the higher microwave 
regions, antennas with thin ‘‘pancake’’ patterns 
are more difficult/expensive to build and the 
resulting narrow vertical beam is at risk of being 
deflected by tropospheric circumstances, with a 
consequential reduction in system margins. 
Physically high level transmitters, omnidirec- 
tionally broadcasting high power, must be 
avoided since they are extremely wasteful of 
both spectrum and hardware resources. 


A functioning high speed network requires 
good availability to end users. Because of this, 
hardware and sites must be selected to provide 
higher up-time than that which is currently 
tolerated for much amateur communication. If 
system uptime of the same order as commercial 
services is required, say 99.9% or better, links 
will generally require line-of-sight (LOS) paths 
and in severe situations, such as_ those 
experiencing marine alr masses, extra system 
margin will be necessary. AS an example, 
obstructive fading produced by nighttime move- 
ment of wet air may require shorter paths, even 
on VHF, to guarantee service. Generally, loca- 
tions with well mixed air, like the Rockies are 
less likely to experience propagation abnormali- 
ties. Coastal locations, and large flat areas with 
water sources, are more likely to require special 
attention. Interference fading on a link will 
generally require increased C/N margin to 
guarantee performance. The Rayleigh distribu- 
tion model probably serves as a useful guide to 
these margins. For typical fading at higher 
microwave 99% uptime may require about 18 
dB excess C/N over LOS values, 99.5% about 


2? dB and 99.9% about 28 dB excess. On many 
shorter (perhaps 30 mile or less) LOS paths, 
these numbers may be unduly conservative. On 
such short links it may be possible to run with 
C/N only 3 to 6 dB above those necessary for 
the desired BER on LOS free space paths. 


It may even be possible in some situations 
to have extra long paths which rely on tropos- 
pheric ducting to provide communication (it’s 
not a bug it’s a feature!), Whether such links 
which are typically only available a few hours or 
less a day can prove useful for periodic but not 
continuous service (like electronic mail 
transfer) is a question which remains to be 
answered. 


At 24 GHz and above, water vapor absorp- 
tion is an item to consider, particularly on 
longer paths. At 10 Ghz and below, it can 
probably be ignored when considering digital 
data links. Path links of sufficient length to 
make it noticeable probably suffer from much 
larger variations due to variations in the tropo- 
sphere. 

An approximate summary of amateur band 
utility for high-speed network might be: 


144 best suited for low speed broad- 
cast 

220 

433 moderate speed broadcast 


user/cell radios 
900 
1250 upper end of broadcast 
2300 beginning of point-to-point 
3400 
5700 
10000 High speed 
24000 High speed and shorter paths. 
Water vapor absorption 
significant on long paths. 


As mentioned above, two classes of net- 
working radios would be presently useful; radios 
for high speed point-to-point connection 
between packet switches and end-user radios to 
give access to the network. 


In the category of inter-switch radios a 
design using inexpensive microwave transceiver 
modules such as found in burglar alarms, 
automatic door openers and speed measuring 
equipment has already been presented at a 
national convention, and will be appearing 
Shortly in a national magazine. These radios 
easily support data at 2 Mbaud and greater rates 
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and can be built for much less than the cost of a 
commercial 2M FM transceiver. This and simi- 
lar hardware should be able to support paths 
between high level switch sites, perhaps a pair 
of mountaintops, separated by 30-40 miles. 
Longer distances are possible with bigger anten- 
nas, or more sophisticated radio hardware, but 
propagational variations over much longer paths 
require prohibitively high system margins to 
guarantee high up-time and multiple short path 
links are preferred. 


User access radios which can be used to 
broadcast within a local cell, as well as to con- 
tact a high level switch, are already available. 
An entry level for new users at 1200 baud or 
other conventional speed should probably be 
provided in every area to encourage network 
growth. Newer and more interesting applica- 
tions will require greater data throughput and 
should provide the incentive for users to 
upgrade their stations to allow this. 


No doubt some of the 250 kilobit/second 
user radios will be pressed into service initially 
for inter-switch communications by using direc- 
tional antennas. This may particularly be true 
in areas where inter-switch distances are neces- 
sarily greater than the distances that are com- 
fortable for microwave. But in the longer term, 
higher “‘trunk’’ data rates will be required and 
these radios should be replaced with dedicated 
microwave hardware whenever possible. 


7. The Future 


The opportunities made possible by a 
functioning high speed amateur network can 
fundamentally change the face of amateur radio 
by augmenting those aspects of the hobby which 
are already enjoyed by so many and by provid- 
ing new applications which may entice a large 
force of new blood into our great hobby. In 
addition to these enhancements the public ser- 
vice aspect of amateur radio may be greatly 
enhanced by providing information age services 
to the public in time of emergency. These possi- 
bilities can greatly contribute to the vitality of 
amateur radio and help ensure the continuance 
of the hobby. 


8. Wrapup 


To make a high speed network a reality 
the biggest hurdles are organizational and not 
technical. Radio hardware, interfaces, and com- 
puters to handle the data are well understood 
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and are becoming available to amateurs now. 
However, to make a functioning entity from all 
the pieces will require a great deal of common 
vision and participation by all parts of the ama- 
teur community. Radio amateurs have tradition- 
ally earned a reputation for an “‘I’ll do it my 
way’ mentality within the hobby. This has, in 
fact, been the source of many of our greatest 
technical achievements! Fortunately, the 
development of a truly high-speed network 
leaves room for this, since local cells may find 
many ways to express their individuality, as long 
as means are found to ‘“‘mesh”’ with the rest of 
the network at the backbone interface level. 


However the physical area and user base 
for a nationwide high-speed network is very 
large, and we must therefore find ways to avoid 
large scale repetitions of ‘“‘repeater wars’’ as we 
implement the network. As we work to design 
and implement the next generation of packet 
networking, we must retain an awareness of the 
need for cooperation, support, and goodwill 
between all of the nation’s packet groups and 
users. This will help to ensure that everyone 
can enjoy the exciting new applications made 
possible. 

Perhaps more than at any time since the 
days of spark, amateur radio needs a well sup- 
ported organization to further the relay (or net- 
working) of our communications. In the midst 
of the many recent discouraging developments 
relative to our spectrum and membership, a real 
amateur network offers great hope and excile- 
ment for our future! 
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ABSTRACT 


Packet radio is often used as a means of accessing computing facilities or, more 
generally, a larger terrestrial network. In this respect, it can be seen as a form of local 
distribution. Similarly, intelligent repeaters interconnecting stations that are not in one 
another's hearing range can be thought of as performing an analogous function. 
Whenever this is the case, alternatives to the popular CSMA access protocol may be 
considered, that are better suited to work in a _ semi-centralized environment. In this 
paper, we describe some versions of one of these protocols (R-ISA), and its integration 
with higher layer ones. 


INTRODUCTION 


Several situations arise where locally sparse users want to access a central facility. 
This may consist of a computing center, a local area network or, in general, a base station 
connected to a long haul transmission network. A typical instance of the latter is in the 
mobile circuit-switched communication network, where a certain number of frequencies 
are allocated to users within an area on a per call basis. In the packet switched 
environment, this problem of local distribution can be effectively solved by means of 
several available multiaccess techniques. Following the classical survey of Tobagi [1] (see 
also [2] for a more recent one), these can be grouped roughly into four categories: a) fixed 
assignment (FDMA, TDMA, CDMA, ...); b) random access (pure and slotted ALOHA, CSMA in 
its various forms, CSMA/CD, ...); c) demand assignment with centralized (polling) or 
distributed control (e.g., token passing, either explicit or implicit); d) adaptive and mixed 
strategies (e.g., adaptive polling or probing, Um, GRA, etc.). Fully distributed access 
methods like CSMA are currently in widespread use in packet radio, where they face in 
the same way the above mentioned local distribution problem and the more general one 
of peer-to-peer communication among any two stations. However, whenever a_ base 
station is present for some reasons, and the local distribution traffic plays a relevant role, 
the semi-centralized nature of the system can be exploited to enhance the characteristics 
of the access protocol. This can be done essentially in two ways: i) by using the base 
station as a means of synchronization (which may be simpler and more easily 
implementable than for instance, slotting the channel); ii) by distributing ‘state” 
information (e.g., channel feedback), that would otherwise be difficult to achieve on a 
radio channel, or would be achievable with longer delay. The latter feature is particularly 
useful to make the access strategy adaptive to load variations. 

The authors have proposed an adaptive protocol of this kind [3] (R-ISA) that retains 
the basic properties of the ISA adaptive strategy for a slotted channel [4]. With respect to 
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the above mentioned classification, R-ISA falls mainly in category d), and exhibits some 
similarities with adaptive polling [5]. 

In this paper, after briefly recalling the basic mechanism of the access strategy, 
we consider some more practical issues related with its implementation. In particular, we 
are interested in interfacing R-ISA with upper layer protocols as AX.25, TCP/IP and 
NET/ROM, as we are currently realizing an experimental network over the 430 MHz 
amateur band, using unmodified TNC hardware. We will therefore describe a possible MAC 
layer protocol and service for R-ISA, and discuss some choices related with the 
integration of new stations within a “local” net served by a base station and with the 
distribution of access rights. The description is informal, and does not attempt to 
rigorously prove the validity of the protocol. A performance analysis of the basic scheme 
can be found in [3]. 


THE R-ISA ACCESS SCHEME 


R-ISA has evolved from the original ISA algorithm [6], in order to exploit the 
presence of a base station, which will be denoted by §&. Let J represent the set of N 
peripheral stations. The scheme operates as follows. § and J alternate their transmission 
periods. A transmission period is recognized between the Beginning-of-Carrier (BOC) and 
End-of-Carrier (EOC) events of either Sor J. Transmissions from S§ are _ conflict-free, 
whereas at the beginning of each transmission period from J, access rights are assigned 
and the actions following will give rise to a channel outcome (collision/no collision) that 
can be observed by §S, and can be either broadcast to the stations in J (that will use it to 
compute the access rights) or directly used by §& to compute the next access rights, that 
will be then distributed to all stations in J. The computation of the access rights is based, 
besides this channel feedback information, also on estimates of the “a priori" information 
on the packet generation rates (in packets/s) Aj, Vie J, of the peripheral stations (each Aj 
can be locally estimated and, at the earliest convenience, transmitted to §&, which will 
either diffuse it by broadcasting or use it directly in the computation). 

On the basis of all the above informations, a data base is kept and dynamically 


updated, consisting in a vector p(t), whose components P; represent the "marginal" 
presence probability of a packet at station i within cycle t (a cycle is the time interval 
made up by the two consecutive transmission periods of § and 7). At each t, given the 
A : ‘ $45.4 
current value of p(t), the vector p(t) is constructed of the marginal probabilities 
. . . ‘. At At, 4 : : 
arranged in non-increasing order (i.e., Pi41 Pj j=l,...,.N-1). This is used to compute the 
number k(t) of stations to be given access right, starting from the one with highest 
presence probability. The number k(t) is obtained by a simple algorithm, that repeatedly 


evaluates the difference between the probability of success and that of no transmission in 
the transmission period of J within the current cycle, given a set of enabled stations that 


initially is made up by the station with highest marginal probability (D; ), and is 
increased by 1 at each evaluation, always including stations in order of non-decreasing 
presence probability. Eventually, k(t) is found as the number such that the above 


difference is negative or null with k(t)-1 enabled stations, whereas it becomes positive 
(and would remain such) with k(t) enabled stations. It is easily seen, for instance, that a 


single station will be enabled whenever P, > 1/2, and that all the N stations would be 
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enabled if the above difference remained negative. As is consistent with intuition, in 
general, enabling a set of stations with a "large" presence probability within the set 
increases the possibility of a collision, whereas a set of stations with "low" presence 
probability within the set may more easily result in an empty transmission period; in 
both cases, bandwidth would be wasted, and there must be clearly a tradeoff. It has been 
shown [4, 6] that the algorithm maximizes the success probability in the transmission 
period of J within the current cycle, under the hypothesis of independence of the 
presence of packets at the stations. 

The updating of p(t) is based on the previous values, the decision taken on the 
access rights, the resulting channel feedback, and the "a priori” information on the 
packet generation rates. It is easily performed if all stations in J are supposed to have 
buffers with capacity of a single packet. The calculation can be split into two parts. First, 
one can consider the situation corresponding to no external inputs, and find the presence 


dats ~tel . ‘ : ‘ , ‘ : 
probabilities P; in this case. It is easy to see that if station i had no access right, then 


=tri : . . ; mae | ~t+1 
; =p; and that if station i had access right and no collision resulted, then p; =0. The 


only case involving some calculations [3, 4] is that of station i having access right and 
getting involved in a collision. As regards the second part of the updating, the peripheral 
stations have a buffer capable of containing a single packet, that is kept until successful 
transmission, and supposing Poisson arrivals with mean Aj, i¢ J we can evaluate the 
probability of a packet generation oj(t) at station i in cycle t as 


oj(t) = 1-c4;T, 
being T; the length of cycle t. The final updating is then 


t+1 ~t+1 
p= 1-(1- p+) [1-04(t)) 


TWO DIFFERENT APPLICATION INSTANCES AND THEIR IMPLICATIONS 


We briefly consider two different cases, that may both occur in the amateur radio 
environment, and that require different handling of radio stations becoming active or 
inactive (i.e., joining or leaving the system). First of all, however, we note three 
characteristics of the above described scheme: i) due to the presence of the base station, 
the performance will be insensitive to stations in J being hidden from one another, the 
only requirement being that they all are in the hearing range of the base station; 11) the 
total number N of stations in J must be known; iii) these stations must be assigned a 
number or "local identification’. 

The first of these is a positive feature with respect, for instance, to CSMA, which 
would be very sensitive to hidden stations (unless using variations thereof, like BTMA 
[1]). We note, in passing, that several simulation results have shown a superiority of R- 
ISA with respect to CSMA, in terms of throughput and delay [7]. The other two 
characteristics require some care in the implementation, and may lead to alternative 
solutions to suit some specific situations. 

A possible topology where the above mentioned advantages and different features 
would appear is that of a "two level" network, as depicted in Fig. 1, where terminal users 
are connected with "low and local" repeaters, and the latter in turm may access “main” 
repeater stations located in dominant position on top of a mountain to ensure a large 
coverage area. The main repeaters may be viewed as forming a backbone network, 
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perhaps using some higher speed link. Typically, the "lower" repeaters and user stations 
situated on the opposite sides of a mountain would be hidden, but within the range of the 
top station. Thus, this situation would be suitable for the application of R-ISA. Since the 
"intermediate" repeaters are fixed and their number does not change frequently, one can 
set the number N as a foreseen maximum of active stations, identify all stations a priori, 
and use the same mechanism as in [3] to allow the possibility that a station switches on 
and off. This consists in assigning a constant default “low” value og to temporarily 
inactive stations, in order to "enable" them less frequently, but with nonzero probability, 
so that they can reconnect when they switch on. Also, since the intermediate repeaters 
under the range of a main one would typically be not too large in number, it is reasonable 
in such situation to centralize computation in the main station, and distribute the access 
rights at each cycle. Note that, if the user stations within each area would continue to use 
CSMA among. themselves and with the intermediate repeaters, the introduction of the 
above scheme would require no change in TNC hardware and software, as it affects only 
the dialogue with the "backbone" repeaters. 

As regards the extention of the procedure to the user stations, for which the 
intermediate repeaters may act as base stations, a littke more care must be taken. Actually, 
two features would appear in this case: 1) user stations are not necessarily tied to an area, 
and can move around, even if they were not mobile in a strict sense; ii) the number of 
stations in an R-ISA population is likely to be larger than that considered before. Due to 
point i), it is no longer possible to permanently assign a local identifier to a station within 
an area; a station entering an area must be given the possibility to execute the access 
protocol even in the absense of this number, and just in order to get one. Point ii) 
requires the usage of more efficient mechanisms to distribute the access rights than, say, 
a bit map (which would be reasonable with a limited number of users), or requires the 
distributed computation of the access rights (however, in this case, one should think of 
recovery mechanisms in case that the channel feedback is not seen by all stations in the 
same way). We briefly discuss here only the first issue. 

A possible solution is to reserve a number, say 0, not for a specific station but as a 
common identification for newcomers. We shall refer to this as an “access virtual 
channel" (AVC). Whenever the AVC is enabled and there are stations waiting to be 
identified, they send a "MAC connection request" to the base station. If only one is waiting 
(and provided it does not collide with a normal packet from a contemporarily enabled 
Station), the base station will recognize the message and respond by releasing a local 
identifier, chosen among the free ones. If two or more are waiting (or the single one 
collides with a normal packet), a randomization mechanism may be used by the waiting 
Stations at the next enabling of the AVC. This behaviour has some analogy with that 
described in [8]. Note that, in case only the AVC is enabled and a collision is seen (because 
there are multiple access requests), the R-ISA updating rule would yield an indeterminate 
form (0/0) in this case for the new presence probability; obviously, the latter must be set 
to 1 for the AVC, that will be thus enabled singularly in the next cycle (by the way, a 
similar behaviour must be taken even when a normal transmission by a _ singularly 
enabled station is corrupted by noise and seen as a collision). We may also remark that the 
presence of the AVC eliminates the need for the use of oq; the rates corresponding to 
unassigned identifiers can be set to zero, speeding up the execution. 


MAC LAYER FRAMES FOR R-ISA WITH AVC 


In this section, we give a description of a preliminary version of the R-ISA MAC 
layer frame formats, that are necessary to implement the basic functions required by the 
protocol. We refer to the AVC case; moreover, we suppose that the computation of the 
access rights is centralized, and that their distribution is effected by means of a simple bit 
map. 
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Obviously, due to the structure of the R-ISA strategy, a first distinction must be 
made between frames pertaining to the base station and those of the peripheral ones. 

In the § to J direction, the following MAC frame types are needed: i) acceptance of 
a MAC connection request (containing the ID of §, the ID of the station in 7, and the 
assigned local identification number); ii) acceptance of a MAC disconnection request; iii) 
information (generally containing an AX.25 frame in the information field); iv) 
supervisory frames. All these frames contain a field with the access rights bit map. 

In the J to § direction, one has again four MAC frame types: i) MAC connection 
request (containing the ID of the issuing station, the base station ID, and the AVC 
number); ii) MAC disconnection request; iii) information; iv) supervisory. 

We will designate the first four types as S-frames, and the second four as J-frames, 
and describe some of them in greater detail. S-frames formats are shown in Fig. 2. All c¢ 
them begin with an 8-bit type field, followed by a bit-map-length field and a bit map field. 
The bit-map-length concides with the highest "active" station number (i.c., the highest 
number among those assigned to stations in J that are currently connected) plus one 
(number O is the AVC, that is supposed unique). Each set bit in the bit map field means 
access right to the corresponding station. Bit 7 in the type field distinguishes between § - 
information and other §S-frame types. The other significant bits are as in the figure. 

J-frames formats are shown in Fig. 3. All of them begin with an 8-bit type field, 
followed by the local ID or "channel" field, that contains the assigned local ID number (or 
0, when the station is still "on the AVC"). Again, bit 7 in the type field distinguishes 
between J-information and other J-frame types. J-information frames contain the 
current value of Aj in the remaining 7 bits of the type field. If bit 7 is set, bit 6 identifies 
either a request or supervisory J-frame. In case of a request-type, bit 5 is used to 
discriminate between connection and disconnection. All MAC frames should be embedded 
within the boundaries of an HDLC frame (flags and CRC). 

An incoming station sends a connnection request on the AVC (i.e., it listens to the 
channel, monitoring the bit map field, until it sees enabling of the AVC, then sends the 
frame). If this is successfully received, the base station § will respond by accepting the 
connection and releasing the local ID. If the request is unsuccessful, for any reason, the 
incoming station will use the randomization mechanism at the following transmission 
attempts on the AVC. During normal data transfer, no ack is needed at the MAC layer. 
Disconnection is effected by sending a disconnection request, that must be ack-ed by §&. 

In case no station in J is connected, § will enter a "dormant" state, and will only 
periodically send a supervisory frame for synchronization, containing the enabling of 
the AVC. 

Other supervisory frame types and possible timeout conditions are under 
consideration. 


CONCLUSIONS 


We have considered some possible application instances of the R-ISA adaptive 
access strategy in an amateur environment. Due to its characteristic features, R-ISA 
seems to be well suited as a local distribution strategy (even if it does not prevent direct 
communications among peripheral stations). This is the case, for instance, of sparse PC's 
that want to access a LAN or another type of fixed network, or an intelligent repeater 
station situated in a dominant position. In order to cope with stations moving in and out of 
the boundaries of the local area defined by a base station and its tributaries executing the 
R-ISA protocol, we have introduced a "common" identification, that has been termed 
"access virtual channel" (AVC). Then, some aspects of the protocol related to this 
mechanism and possible formats of the necessary MAC frames have been briefly 
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discussed. In fact, the necessity of specific MAC laver frames is one of the characteristics 
that differentiate this protocol with respect to simpler ones, e.g., CSMA. On the other hand, 
the increased complexity may turn out to be justified, at least in some cases, by the 
achievement of better performances and the insensitivity to hidden stations. We hope to 
further verify this conviction through the experimental setup that we are preparing and 
the help of the local HAM community. 


REFERENCES 


[1] 


[2] 


[3] 


[4] 


[S] 


[6] 


[7] 


[8] 


F.A. Tobagi, "“Multiaccess protocols in packet communication systems", IEEE Trans. 
Commun., vol. COM-28, pp. 468 - 488, April 1980. 


S.R. Sachs, “Alternative local area network access protocols", IEEE Commun, Mag., vol. 
26, pp. 25 - 45, March 1988. 


M. Aicardi, F. Davoli, A. Giordano, "Radio_ISA_Net: a single-hop centralized packet 
radio network for PC-to-mainframe interconnection", IEEE J. Select. Areas Commun., 
vol. 7, pp. 219 - 225, Feb. 1989. 


M. Aicardi, G. Casalino, F. Davoli, “Independent Stations Algorithm for the 
maximization of one-step throughput in a multiaccess channel", IEEE Trans. 
Commun., vol. COM-35, pp. 795 - 800, Aug. 1987. 


J.F. Hayes, "An adaptive technique for local distribution", IEEE Trans. Commun., vol. 
COM-26, pp. 1178 - 1186, Aug. 1978. 


M.G. Hluchyj, "Multiple access communication: the finite user population problem", 
Ph. D. dissertation, Dep. Elec. Eng. Comput. Sci., Mass. Inst. Technol., Cambridge, MA, 
Oct. 1981. 


M. Aicardi, F. Davoli, A. Giordano, S. Zappatore, "A multiple access adaptive protocol 
for mobile-to-base-station packet communications in a_ structured environment", 
Proc. 2nd PROMETHEUS Workshop, Munich, Oct. 1989 (to appear). 


J. W. Ward, GO/K8KA, "A brief note proposing non-ALOHA access techniques for 


PACSATs", Proc. 7th ARRL Comput. Networking Conf., Columbia, MD, Oct. 1988, pp. 182 - 
185. 


35 


36 


ie 





— Terminallink —— R_ISA link 


a "High" repeater and R_ISA master 


"Low and local" repeater 


Fig. 


1 


© Terminal station 


A) Bit-map length|| Access rights bit-map 





[Frame type _ 
B) Bit-map length | 
C) Bit-map length] [ Station 1D _| [Base Station ID] [ Local ID | 


bit7=0 ___ S-Information MAC Frame 








Access rights bit-map 












Frame_type 





bit 6 = 0 | : 
Connection or disconnection accepted 


bit 7=1 





Supervisory Frame 


bit6 = 1 


Fig. 2. S-frames: A) S-information MAC frame; B) S-supervisory frame; 
C) connection /disconnection accepted frame 


Frame_typ [Local ID AX.25 frame 


B) Local ID STATUS | 
C) Local ID _—‘|[_ Station ID 








Base Station ID 






Frame_type 





bit7=0 ___T-Information MAC Frame 


Frame_type 





bit6 =0 Ie 
: — Connection or disconnection request 





— Supervisory Frame 
bit6 = 1 


Fig. 3. 7 -frames: A) T -information MAC frame; B) T -supervisory frame; 
C) connection/disconnection request frame 


37 


38 


Implementation of a 1 Mbps Packet Data Link, 
Using 10 GHz RF 


by Glenn Elmore N6GN 
and 
Kevin Rowett N6RCE 


Abstract 


Presented is the design and the authors' experiences with 
implementation of an Amateur Radio Packet Data Link operating at one 
megabit/sec. The technology used is FSK modulation of Gunnplexors in the 
10GHz amateur RF allocation. The digital interface is to an IBM PC bus using 
the PCLAN (SYTEK 6120) adapter card running the KA9Q implementation of 
TCP/IP suite of protocols. 


Need for faster links 


Faster links support the movement of higher traffic volumes. This can 
also be stated as latent demand for service. If a user knows it will take longer 
to deliver a mail message electronically, than to put a stamp on it and send it 
via the USMAIL, then he won't even bother with E-mail. 


Higher traffic volumes also come as a result of new applications 
attracting more users. Examples of new applications include DX spotting 
network software, on-line call book databases, and distributed applications 
such as the ARES/Finder program by WN6I and N6KL. . 


Some applications have real-time response time criteria, such as remote 
control of repeaters and digitized repeaters. Higher baud rates are needed 
before these applications can even become usable. Keyboard to Keyboard 
QSO's could be viewed as a real-time application. 


Why use Microwave for Higher Speed Packet? 


The best explanation is simply the price to performance ratio. For about 
the same expense as a complete 2M packet station running at 1200 bps, one 
end of a 1 Mbps, 10 GHz link can be constructed. Add in the benefit of being 
able to build it versus buy, and there is no comparison. 


The major cost items are the Gunnplexor ($50), the parabolic reflector 
($35), and parts for the I/O adapter ($150). 


Bandwidth is another major factor in the choice of microwaves. Data 
rates and bandwidth needed are directly proportional. In fact, the microwave 
bands are the only ones with sufficient not in-use bandwidth to support 
higher speeds. 


Another major factor in the choice of microwaves is antenna sizes. At 
microwave frequencies, antennas of reasonable size are better able to focus the 
transmit power in the direction desired and not waste it in directions where 
the receiver is not positioned. 


Microwave Modem Theory of Operation 


The microwave modem is based on Gunnplexor transceiver units used 
in such items as motion detectors, radar guns, and radar detectors. The model 
chosen for the initial prototyping is the NEC ND751AAM. Other units, 
including the MA/COM will work as well. 


The units operate in pairs and the transmit frequencies differ by the first 
i-f frequency of the receivers. Therefore the LO for the first conversion stage 
is the locally transmitted signal. Data carrier Detect (DCD) will not be present 
in either unit until both units are transmitting and the antennas aligned. 


The Gunnplexors produce 5 to 10 milliwatts of power, which is feed into 
a parabolic reflector. A pyramidal horn and a short section of waveguide are 
built to properly illuminate the reflector. With a two foot diameter reflector 
and a f/D of .46, the system will have a gain of 33 dB. 


Modulation is FSK. Frequency shifting of the Gunnplexor is done by 
varying the bias voltage of the transceiver with a LM317 adjustable three 
terminal regulator. ECL differential drivers ( MC10116 ) are used to allow 
long data lines with some noise immunity. 


The FSK receiver performs a second conversion with the second LO 
running between 135 and 165 ( nominal 150 ) producing a second i-f of 
45MHz. Detection and conversion is performed by a MC13055 FSK IC. This 
chip is spec'd to run at 2 Mbps, but we have pushed it to 10 MBps. Data out is 
in the form of ECL differential drivers. 


Because the Gunnplexors are not frequency locked and may wander with 
temperature and over time, an AFC is implemented on the incoming data 
and adjusts the second LO to keep the data centered on 45 MHz ( the second i-f 
). A search oscillator is included as well to sweep the second LO should the 
two units loose carrier lock. 


The Gunnplexor, modulator, and a receive pre-amplifier assembled with 
MMICs are all mounted in a box at the feed point of the parabolic reflector. 
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Output from this box, and down from the pole is the first i-f -- 105 MHz. The 
remaining FSK receiver components are assembled in a box adjacent to the 
computer. One end of a link consumes 450ma @ 12VDC. 


In the initial units, an audio channel was provided to assist in debugging 
the digital side and help with alignment of the antenna. 


Digital Theory of operation 


The original intend of the project was to use standard issue PC 802.3 
adapter cards. N3EUA had the idea to slow them down to 2 Mbps by changing 
the crystal from 20 MHz to 4 MHz. However, commercial ethernet adapters 
just can't be slowed down so easily. The serial interface chip in each 
commercial adapter quit working if it wasn't within .001% of 10 Mbps. This 
chip accepts the TTL NRZI frame format the 802.3 controller chips put out, 
adds clocking, and produces Manchester encoding. 


The PCLAN card introduced by IBM some years ago runs 802.3 at 1 Mbps 
over CATV coaxial systems. This card is also known as the SYTEK 6120. It 
has on a full length PC adapter card a 80186 microprocessor, RAM, ROM, 
82586 802.3 controller, and a custom serial interface chip. Modulation 
technique is FSK. The unit is full duplex and operates split. The S/W on this 
card implements the IBM PC Netbios interface. 


Along with the IBM PC network program, this represented IBM's first 
PC LAN product. This setup is ideal for Amateur Radio as well. Build a pair 
of microwave links between your QTH and a good friend's QTH. Now you 
can access each others hard disk. 


To use the PCLANA with the microwave modems, connection is made 
to the TTL serial interface chip directly. The RF modem on the card is not 
used whatsoever and is disconnected for this application. 


Connection to the serial interface chip requires a TTL to ECL converter 
and a DCD generator. The microwave modems supply continuous DCD, 
since they are always transmitting/receiving. The microwave DCD really 
indicates DSR. 


The serial interface chip doesn't use DCD to delimit data, but to 
determine if the Ethernet has been jammed by a hot transmitter. If DCD is 
active beyond a fixed time amount, it will declare the cable jammed, and 
enter a state where it refuses to do anything. 


While DCD is used to detect jammed cable, the adapter will not sample 
for 802.3 pre-amble until DCD is true. The interface adapter would bring DCD 
true on the first low to high data bit transition, and also start a re-triggerable 


one shot. Each low to high transition would restart the one-shot. When the 
one-shot expires, DCD is brought false. 


Initial testing of the interface was with the IBM PC network program. 
This software package allows PC's to share disk drives. Initial testing was 
easy. Start the network program, separate the,,PCs by some reasonable 
distance, and copy the entire hard disk from one machine to the other. 


This could have been a place to stop, but not for us! A packet driver was 
implemented using the datagram mode of the PCLANA. FTP, inc placed in 
the public domain a specification for a standard way to interface PC based 
TCP/IP software packages to ethernet cards. The intent was to have one way 
to access all the different cards commercially available. When a new card 
came along, someone could write the driver to support it. 


The ever popular KA9Q package has a provision to ‘attach’ interfaces as 
packet drivers. Using this interface made the most sense, and has worked 
well. 


Our Experiences 


Aligning the parabolic reflectors turned out to be the most challenging 
part. The path must truly be line of sight (LOS). Microwave propagation is 
not like VHF or even UHF. The dishes must be pointed at each other within 
two degrees and have stable mounts before any signal is heard, unlike VHF, 
where the beam can be rotated around looking for the best signal level. 


Data flowed with low BER down to about 12 dB C/N. Over the 13.50 
mile test path, C/N was 20 dB, with two-foot reflectors. 


Usage in Norcal 


An interesting group of advanced packeteers reside in the San Francisco 
Bay Area. This group has been attempting to form a general use network 
based on the TCP/IP suite of protocols. This network architecture is two level 
hierarchical. Each group of Amateurs that have good RF paths to each other 
form a cell. Each cell has an IP router in it with paths to other cells. 


Since the microwave modem is by nature point to point, not broadcast, it 
usage is to link the IP routers together. The initial usage in Norcal was to link 
the Cupertino cell IP router to the San Jose router. 


Futures 


Better DX with this design could be achieved with optimization of the 
receiver detector bandwidth. Larger diameter dishes will help the DX as well. 
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Increasing the reflector diameter from two feet to four feet will provide 6 dB 
of gain, for an increase in four square feet of wind load. 


Work is in progress to implement inexpensive 250-500K baud FSK units 
in the 900 MHz and 1200 MHz Amateur allocations. These bands still have 
acceptable broadcast qualities for individual user access. 


The choice of the PCLANA was a quick way to get on the air and test. 
What the ( near ) future holds, is implementation of K3MC's Awesome I/O 
PC adapter card, described in previous conference papers. The author's 
presently are experimenting with K3MC's prototype of the awesome I/O, and 
hope to have replaced the PCLANA cards with awesome I/O, by the time this 
paper is presented at the conference. 


Summary 


With the introduction of reliable megabit links, applications providing a 
variety of services can begin to take shape. 


The author's hope to provide a reliable Amateur Radio Packet network 
with data throughput greater than that available to the user of TELCO dial 
modems (2.4 to 19.2). This kind of data and networking would provide an 
environment and inducement for development of applications, rather than 
just keyboard to keyboard QSO's. 


To gain the maximum benefit from higher speed links, Amateur Radio 
Data Networks will require formation of architecture and planning. No 
longer will it make sense for a user to buy a radio, antenna, TNC, plug them 
into a PC, and dial in a frequency to go BBS hopping, or NET/ROM hopping 
Otherwise the network will never be able to provide reliable services to the 
intended users. 


The view that "I've a Ham license, just like you, and I've got as much 
right to a frequency as the next Ham", will have to give way to cooperation, 
organization, and planning. 


Creating the level of organization and cooperation needed is perhaps a 
greater challenge than the technical accomplishments needed to implement 
an Amateur Radio Packet Network. It's time for the ARRL to re-examine 
(review ?) it's charter. 


A PERSONAL PACKET RADIO MAILBOX USING ROSERVER 
Automated Packet Radio For Individuals 


Andrew Funk, KB7UV 
Radio Amateur Telecommunications Society 
14-23 3lst Avenue « Apt. 4A 
Astoria, NY 11196 USA 
718-956-9927 
kb7uv@kd6th.nj.usa.hamradio.org.iso 


This paper describes use of ROSErver' — Packet Radio MailBox System 
by Brian Riley, KA2BOE, as a Personal Packet Radio MailBox. 
ROSErver has features specifically intended for this application. 

Personal MailBoxes, when operated correctly, enhance the Amateur 
Radio Packet Network. 


Advantages Of Personal MailBox Operation 


Personal Packet Radio MailBoxes (PRMBoxes’), when properly configured, 
provide advantages to both the operators using them and the local network in 
which they operate. 

The PRMBox operator no longer has to wait for others to clear the area 
Packet Radio MailBox System to send or receive messages. Instead, packet mail 
is "home delivered," and outgoing mail is entered on the PRMBox itself for 
automatic forwarding. 

The computer running a PRMBox is always available for other use. No one 
else depends upon the PRMBox being available, as it is a personal system. The 
PRMBox operator can simply exit the program, do other work on the computer, 
and when done, return to the PRMBox. 


‘ ROSErver is the RATS Open Systems Environment Server. See Appendix 1 for ROSErver program availability. 
* There is debate whether the correct plural is PRMBoxes or PRMBoxen. 
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PRMBoxes, when properly configured, limit their use of the packet network 
to "off-peak" hours. This reduces channel congestion by spreading activity over 
the day. 


Requirements 


Anyone trying to set-up and run a PRMBox should be comfortable with 
packet radio and MS-DOS operation’. 

Hardware required is a packet station (radio, TNC, antenna, power supply) 
and an MS-DOS computer, such as a "PC-Clone." The PC should have at least 
384K of RAM memory. MS-DOS version 3.3 or higher is suggested. A hard 
disk is not necessary, as a PRMBox can run on two 369K floppies. However, 
as ROSErver frequently accesses disk files, performance is substantially 
improved by a hard disk. 

In addition to ROSErver, the only software required is an editor for the 
ASCII text files used for configuration. Appropriate editors include the Norton 
Editor, WordPerfect’s Program Editor, and the editor included with Procomm 
Plus. As ROSErver is written to operate well under both DoubleDos and 
DesqView, either of these programs may be used to allow other computer use 
simultaneously with running the PRMBox. (As mentioned above, the operator 
can simply exit the PRMBox program to do other work on the computer. 
Multi-tasking may be desireable, but is not necessary.) 

The most important requirement is not under the control of the person 
setting up a PRMBox. A Host MailBox, with a cooperative sysop, is essential. 


Host MailBox 


A Host MailBox is a Packet Radio MailBox System, or similar PBBS, 
available for use by area radio amateurs, which is part of the auto-forwarding 
packet radio network. The prospective PRMBox operator must have a 
dependable RF connection with the Host. 

Many of the features described in this paper are specific to ROSErver as 
both PRMBox and Host. A ROSErver PRMBox will work with a Host running 
any of the auto-forwarding PBBS programs (W@RLI, K3RLI, MBL, MSYS, 
AmigaBBS, etc.), but some features (especially REQMSG) will not be supported. 

The Host MailBox sysop must accept automated users of his/her system, 
and make provisions for each PRMBox. Dave Elliot, KD6TH, is sysop of an 
active PRMBS in the New York—New Jersey area. KD6TH-4 is host to 
several PRMBoxes, including the author’s. These are Dave’s conditions for 
PRMBoxes operating with his system as host: 


* This paper describes an MS-DOS-based PRMBox. Other PBBS programs for other computers may be similarly 
adapted, but may not support all the features described here. 


1. Messages are for first-party use only. No messages will be handled for 
third-parties on the personal system. The idea is that the mailbox is a 
personal mail box, not a part-time PBBS. So the personal mailbox user 
should not accept traffic for others, but is free to forward through the main 
PBBS to anyone, and will get, in return, all traffic addressed to him 
automatically forwarded. (Exceptions are made for stations with more than 
one licensed amateur.) 

2. Mail forwarding to the personal systems will be only during non-peak hours, 
usually midnight to 8 AM, or 19 AM to 4 PM weekdays. This enables the 
better utilization of the PBBS, and does not interfere with manual operators 
using the BBS. 

3. NO Beacons by the personal mailbox. They should be unnecessary, and are 
certainly unwanted. 


4. The systems should not poll for traffic, messages will be forwarded auto- 
matically. A "poll" for new bulletins is acceptable as long as not overdone 
— say no more than one per day. 
These guidelines provide benefits for all concerned — they lets the 
automated personal system operate efficiently without affecting the other 
users or tying up the main PBBS. 


Special Features of ROSErver 
Headers 


ROSErver automatically inserts a header at the top of each entered 
message, conforming to the RFC-822 standard. This is a sample: 


Date: 1§ Aug 89 23:38:44 EDT (Thu) 

From: kb7uv@kb7uv.ny.usa.hamradio.org.iso (Andy Funk) 
Message-ID: <3335@KB7UV> (Astoria,NY) 

Reply-To: kb7uv@kd6th.nj.usa.hamradio.org.iso 

To: kb4cyc@kb1bd 

Subject: Script & event info 


The optional "Reply-To:" field is especially designed for PRMBox operation. 
It directs replies to the Host, which is a "known" system. Replies generated on 
a ROSErver are automatically addressed to the "Reply-To:" address, if included. 


As with other MailBox—PBBS programs, ROSErver automatically 
executes programmed instructions at specified times. These events may be 
flexibly programmed. Events may be scheduled for each cycle (usually set as 
once each hour), each odd cycle, each even cycle, each third cycle, etc. 
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Additionally, events can be scheduled to run only between certain hours. 
ROSErver can execute, as events, both ROSErver commands and DOS 
commands. 

Packet networks operate on UTC, while most human beings operate on local 
time. Computers running ROSErver can have their clocks set to any time zone, 
and UTC will be determined by the program. 


Wildcards are accepted by ROSErver’s forwarding commands. This 
frees the PRMBox operator from maintaining complex forwarding files. The 
simple command: 

swap HostMailBox * 
tells ROSErver to send all outgoing mail to the Host MailBox and then poll for 
incoming mail. (See Appendix 3 for examples.) 


Modes 
ROSErver includes a versatile terminal mode, including capture-to- 
disk. A separate program is not needed for manual packet operation. 

In addition to over-the-air operation using TNCs, ROSErver supports 
password protected modem access. All features are available via modem, with 
the addition of protocol (X-, Y-, and Z-modem) uploads and downloads, 

Also password protected is Remote Sysop mode, which grants additional 
control both over-the-air and via modem. Among the special features available 
to Remote Sysops is Doorway access. This feature provides access to DOS 
programs from within ROSErver. 


Instructions for connecting to stations are stored in a special file’. 
These connect scripts can handle direct, digipeater, ROSE Switch, Net/Rom, 
and hybrid connection paths. Scripts can evaluate received responses and act 
upon them, open and close disk capture files, etc. Automatic scripted 
connections are used for events, and can be called manually for use in terminal 
mode. 

Automatic address translation lets the PRMBox operator use aliases when 
sending mail. These aliases, with their translations, are kept in a simple text 
file (translate.rs). If this file contains the line: 

tom §w2vy@kd6th.nj.usa.hamradio.org.iso 
messages entered to "tom" will be readdressed, and sent, to: 


"w2vy @kd6th.nj.usa.hamradio.org.iso." 


* Samples of this "calldir.rs" file are given later in the text, and a complete file example is provided as Appendix 4. 


The Console 
Security and versatility are provided at the computer running 

ROSErver, called the console. Hitting the ESCAPE key brings a "Login:" 
prompt. Hit ENTER to log on as the sysop, or enter a callsign to log on as a 
user. In either case ROSErver will ask for a password. This feature both 
provides password security at the console, protecting the PRMBox from one’s 
children, officemates or roommates, and allows multiple users of the PRMBox. 
(Multi-user PRMBoxes are appropriate for clubs, schools, shared workplaces, 
emergency management offices, actual emergencies, public service events, etc.) 
Console use is also subject to a timer. If the PRMBox user is interrupted 
during a session at the console, the system will automatically return to on-air 
mode after the configurable timeout interval. 


Message Handling 
Unique to ROSErver is REQMSG. This is a way to request specific 
messages for forwarding to the requesting station. This feature, combined with 
connect scripts which automatically generate a list of new public messages on 
the Host MailBox, allow ROSErver PRMBox operators to be complete 
participants without ever manually connecting to the Host MailBox. This is 
described more completely under Message Lists. 

Often the same message must be sent to several people. If the Host 
MailBox is a ROSErver, a single message may be sent to rmail (remote mail) 
at the Host, listing the recipients. When the Host receives it, the message will 
"explode" into the desired individual messages. 

ROSErver also has a powerful distribution facility for managing mailing lists. 
This topic will be addressed in a future paper from the Radio Amateur 
Telecommunications Society. 

Killed messages are marked for deletion, but not immediately removed from 
the system. Accidentally killed messages may be recovered within ROSErver, 
without resorting to "unerase" programs (such as Norton Utilities, etc.). 

Flood distribution using Bulletin IDs, or "BIDs," is fully supported. 
ROSErver also supports hierarchical routing. 


Message Lists 

A scripted connect can be programmed to log onto the Host MailBox, 
open a capture file, get a list of new public messages from the Host, close the 
file, and log off. These sample scripts are used by the KB7UV-15 PRMBox 
when connecting with the KD6TH-4 host: 


Script Comments 

>1 KD6TH begin script #1 for KD6TH 
@KD6TH-4 connect to KD6TH-4 

e#* BOF end of script 
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>2 KD6TH begin script #2 for KD6TH 


FO list.th open disk file "list.th" 

@KD6TH-4 connect to KD6TH-4 

&2 ignore first 2 lines received 

+ MailBox> success ts indicated by "MailBox>" 
?*** DISCONNECTED failure by "*** DISCONNECTED" 
: send "I" after success 

.setmsg top at next success send "setmsg top" 
a at next success send "B" 

ee* EOF end of script 


Multiple scripts can be used for the same station. In the sample above, 
script #1 is a simple connection to the Host MailBox. This script is used when 
forwarding outgoing messages. Script #2 creates a disk file (“list.th") containing 
a list of all new messages on the Host. The command "setmsg top" used in the 
script sets the “last message read" pointer on ROSErver systems to the current 
high message number. It is included in the script to avoid duplication in the 
message lists. 

The message list may be left as it is, a disk file, or it can be automatically 
turned into a message on the PRMBox by using the make command as part of 
the event file: 

M 898 poll C2 KD6TH 
M $848 make kb7uv list.th list.th 
D 9898 del list.th 


During the 800 UTC event cycle’ a connection will be attempted to 
KD6TH via the COM3 port using script #2 ("C2" above). Then a message will 
be created to kb7uv titled "list.th" from the file "list.th." Then the disk file will 
be deleted, cleaning things up. 


ROSErver supports remote message requests using REQMSG. 
REQMSG operates in the same way as REQDIR and REQFIL, but for 
messages instead of directories or files. If the Host MailBox is a ROSErver, a 
PRMBox operator can simply read the list of new messages (generated above), 
note which messages are of interest, and request them with a REQMSG. Ona 
ROSErver this is simplified by using the GET command: 


getmsg msg#,msg#,....msg# host 


* 9898 in the example indicates begin (98) and end (98) hours. The events in these examples happen only during 
the 9899 event cycle. 


ROSErver will generate the request message, using correct syntax. (GET can 
also generate request messages for files, directories and QTH information. See 
the ROSErver documentation for further details.) 


An enhancement under development for ROSErver is REQLST. This will 
eliminate the need for complicated connect scripts to generate message lists. 
Instead, they will be handled similarly to other remote requests. 


Before Setting-Up A PRMBox 


First, get a copy of the program you will be using. (See Appendix 1 for 
how to get ROSErver.) Print and read the documentation provided.° 

Communication with, and permission from the sysop of your Host MailBox 
is essential. He/she may have rules you must follow, such as those provided by 
Dave Elliot, KD6TH (see Host MailBox, above). You'll need to be assigned 
time windows (minute of the hour and hours of the day) for your event 
scheduling. Your Host sysop may also wish you to use a distinctive SSID for 
your PRMBox. (In the New York—New Jersey area, personal MailBoxes use - 
15.) 

Only after you have received your Host sysop’s permission should you 
operate your PRMBox in automatic/unattended mode. 

Follow the documentation to install your program. Sample ROSErver 
PRMBox configuration files (config.rs, event.rs, and calldir.rs), as used by the 
author, are provided as appendices to this paper. Use them as guides for your 
configuration. 


Using A ROSErver PRMBox 


The author has used a ROSErver PRMBox for over two years. It makes 
packet operation much more convenient in the hostile New York—New Jersey 
RF environment. 

Brian Riley, KA2BQE, is the principal author of ROSErver. He is 
responsive to the special needs of PRMBox operators. Each revision to 
ROSErver has featured significant enhancements designed specifically for 
PRMBox use. Brian would like more people to join the development effort by 
running the program and sharing their experiences. 

KD6TH-4 and KB1BD-4 are Host MailBoxes for several ROSErver 
PRMBoxes. Many of these PRMBox operators send and receive large volumes 
of mail. Before their PRMBox operation they had to "slug it out" with other 
manual packet operators during "prime time." Now their traffic is handled 
automatically, during "off-peak" hours, and the host MailBoxes are more 
available to manual users during "prime time." 


* ROSErver is a continuing project under development, and the formal documentation is not always fully up-to-date. 
Be sure to read any “.rme ("read-me") files. 49 
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Commands 


Using a PRMBox is easy. The console behaves much like an on-the- 


air PBBS connection, but with instantaneous response. 


following commands: 


ROSErver supports the 


@ ? b bell bye c 
chat clean cmds compress d del 
deluser dir distrib door e e(@ 
e< e> eb ed edit eh 
ek el ep es et event 
flood fwd get getdir getmsg getqth 
h heard help home import info 
k kd kh kl km kp 

kt | 1@ |> l< Ib 

lh list lk ll Ip ls 

It lu m mail make name 
poll pollf port r reply rl 

rm rmail S sb sb$ sbf 
search servmsg setmsg showzip sp SS 

st Status swap t u V 

vl ver X 


When sending or editing messages at the console, PRMBox operators can 


access their favorite text editor while remaining within ROSErver. Old 
messages may be kept for reference, and are available for viewing at the press 
of a key. Files may be made into messages and messages can be saved as files. 
The major message options are: 

Sysop Message Editor commands: 

[A]rchive/kill message [C]hange direction [E]dit message header 

[File message [H]old message [K]ill message 

[N/Y] status change [Qjuit mail [R]ead message 

[S]end reply [T]ext edit (con) [VJerbose read 

[?] display this help [cr] RETURN/ENTER next message 


Manual Operation 
Manual packet operation is also available within ROSErver. 

Terminal Mode is just that — the console is directly connected to the TNC. 
Terminal mode can optionally capture activity to disk. 

ROSErver’s automatic connections can be called directly from the console. 
Upon script completion the program automatically enters terminal mode. 

Automatic forwarding may also be manually initiated. Following a terminal 
mode session with the Host MailBox, ROSErver can initiate auto-forwarding 
without breaking the packet connection. 


Those who do not want to leave their computers on all the time may 
still take advantage of many benefits offered by a PRMBox. Operated this way 
the PRMBox functions similarly to automatic programs designed for commercial 
services. Messages can be written, read and replied to on the PRMBox — 
"offline." Message transfer between the PRMBox and Host Mailbox must be 
manually initiated. Although they will probably be done during "prime-time," 
these "online" actions will take much less time than the same traffic handled 
manually on the Host. While not as advantageous as fully automatic operation, 
a semi-automatic PRMBox still helps the network by speeding traffic flow. 


Conclusion 


ROSErver — Packet Radio MailBox System is excellent as a personal 
packet radio mailbox, especially when the same program is used by the host 
system. ROSErver’s advanced features allow the PRMBox operator to be a full 
participant in packet without needing to ever manually connect to a bulletin 
board. 

Those with large volumes of personal packet traffic should consider 
operating a PRMBox. This will help their local network, by moving their traffic 
to "off-peak" hours, and add flexibility and convenience to their packet 
operations. 
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Appendix 1: ROSErver Sources 


ROSErver is available for download on CompuServe’s HamNet Forum, DL9, 
as well as the following landline BBSs: 


W2XO RBBS — (699) 859-1916 3/12/2499 baud, 8/N/1 
Supports Xmodem, Ymodem, Kermit, MNP. 
Operated by Tom Sundstrom, W2XQ. 


RTC RBBS — (699) 654-9999 3/12/24/969@(HST) baud, 8/N/1 
Supports Xmodem, Ymodem, Kermit. 
Operated by Terry Rossi. 


RATS UNIX — (291) 387-8898 1269 baud, 7E1 
Supports Xmodem, Kermit will be added soon. 
The Radio Amateur Telecommunications Society maintains this Unix 
system for support of RATS projects, including ROSErver. At the 
"login:" prompt enter "rats" (lower case!), no password is needed, and 
follow the directions provided. 
Operated for RATS by Gordon Beattie, N2DSY. 


The author will provide copies of his system, complete with configuration 
files. Send formatted MS-DOS diskettes (two 5.25" or one 3.5"), a diskette 
mailer, and return postage. 


The principal programmer of ROSErver is Brian B. Riley, KA2BQE. He 
can be reached the following ways: 


Mail: c/o MorningStar Keep, Ltd. 
Post Office Box 38 
Medford, New Jersey #8055 (USA) 


Packet: ka2bqe@wb2mnf.nj.usa.hamradio.org.iso 
CompuServe: 71429,3543 
USENET: rutgers!hotps!n2dsy-4!ka2bqe 


Appendix 2: Configuration File 


This is the configuration file used by the author with ROSErver version 
0.99g, $8/19/89, operating as a PRMBox: 
099g 08/19/89 
# 


# CONFIG.RS for KB7UV-15 
# 
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# Local Console Port 

LCE 15 15 0 0000 

Connected 

# ANSI Color keys - background 

# (Q-black, 1-red, 2-green, 3-brown, 4-blue, 5-magenta, 6-cyan, 7-lt gray 

# 

# ANSI Color keys - Text 

# Q-dk gray, l-orange, 2-green, 3-yellow, 4-blue, 5-magenta, 6-cyan, 7-white 
# 


# Color strings for port [Text Color],[Background Color] 


# 

3,4 

# (A port) COM1 would go here if it were being used 
# ------ Above this point is all Port A ------ 


# B,C,D,E ports could be in here 
Ht 


# KB7UV-15 is set up for COM3, Port C, because that’s where the TNC is. 
# 

 ------ COM3 Port TNC, Ham calls only ----- 

# 9600 baud - only for newer TNC2 clones or with TL084 in place of LM324s 
CTH 7 15 4800 

145.07 MHz 

7,4 

YES (is TNC2 or compatible) 

YES (a unit capable of supplying DCD for CONN/DISC indication) 
NO (send a ‘mail for’ beacon on this port) 

NO 2303 10000 (Download window active ) 

# String to shutdown mon and conn for this TNC 

conok off 

mon off 

BT [System in use by User] 

beO 

eke EOF 

# string to be sent to TNC when going INTO TERMINAL MODE 
se 50d 

cr on 

cp off 

ike EOF 

# string to be sent to TNC when coming OUT OF TERMINAL MODE 
se $7f 

cr off 

cp on 

“kk EOF 

# String to this TNC when going back online awaiting connection 
mycall KB7UV-15 

se $7f 

cr off 

cp on 

maxf 2 

retry 12 

mon on 

conok on 
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be 0 

eee EOF 

# optional appendage to forwarding header, (line must be here but may be 
# be left blank 

PRMBox 

NO 1004 10000 (Forward window not active) 

# This EOF is the end of ports in general 

+e" EOF 

# ----------------- end of port configurations ---------------------------- 

# 

NO (send Bell characters to console in text i/o) 

a 

#Color String of BBS output 

3,4 

#Color String of Local Status Display 

7,1 

# String sent out to TNCs when other port busy 

BT | BBS in use on other port | 

BEO 

i EOF 

# Normal BBS prompt 

$Tz, $N msgs @$O MailBox> 

# Remote Sysop string 

Next?$H 

# Local CONSOLE prompt 

At $Tz: [SOKb] $N msgs, last #$L>$H 

# Setup into normal logged user 

PACT A 14 

ie a EOF 

# Setup into remote sysop 

PACT A 8 

+ EOF 

# TNC shutdown string 

conok off 

mon off 

em EOF 

# Call of this station - do not use SSID it gets stripped anyway 
KB7UV 

# Hostname/Domain specification, your call is derived from this also 
kb7uv.ny.usa.hamradio.org.iso 

# 
# Reply-to host_system name place "NONE ”’ (include space) if you receive mail 
# at your own system. If you are personal bbs and receive mail from another 
# host system, fill this line in with host name of same form as domain name. 
# If it is used it is in the form of kd6th.nj.usa.hamradio.org.iso. 

# 

kd6th.nj.usa.hamradio.org.iso 

Astonia, NY 

Andy Funk 

help.rs 

menu.rs 

info.rs 


event.rs 

calldir.rs 

fwd\ 

log.rs 

mon.rs 

# user accessible files area 

files\ 

# use upload\ as name for the directory - if it does not exist uploads go 
# to files\ path of tree specified by user, if it does all uploads 

# go here 

files \ 

# directory that messages texts will reside 

mail\ 

# directory that temporary file/mailmessage upload will reside, usually 
# the same as the directory for the final texts, but may be specified 

# as an alternate in case you have a RAM disk available. This would 
# increase the speed of MAIL and RMAIL enormously. 

mail \ 

mail.dat 

user.dat 

# name and path of file to archive mail 

oldmail.kld 

6 (number of consecutive bad commands til disconnect) 

100 (Kbytes minimum disk space - turns off S and U commands) 

20 (Kbytes of space above minimum for disk full to be turned back off) 
# ---- Logging Options ------ 7 

YES (Turn on logging) 

YES (Log file transfers) 

YES (Log message events) 

YES (Log local events) 

# ----- Remote SYSOP Password String --- may be up to 240 characters 
10 THIS-IS-THE-PASSWORD-STRING-FOR-REMOTE-SYSOPS...READ-THE-ROSERVER- 
DOCS! 


# This string starting in column 4 as a string from which the program will 

# generate 10 random numbers that represent positions in the string, (L = 0) 

# You may have it generate up 16 digits, the program will take any number 

# you give it, but will cut it back to 16 if it is over! The password response 

# is case insenstive and may not include spaces. The character set is the 

# standard ‘low order’ (that is printable ASCII 32-126) ASCII set. The 

# string you set up may be upt to 240 characters long and may, as mentioned 

# above, include spaces in the middle of the string. 

# **** IF YOU SET IT TO 0 - no password will be required **** 

AAP esses sci einen i i cue cla sas 

# ----- Event Scheduler Timing parameters ----------- 

20 MIN 60 CYCLE 4 OFFSET (Parameters are positional MUST be in 1,3,5 pos.) 
# ----- Message Handling parameters ----- 

NO (for non-F type messages remove message and text file immediately on fwd) 
YES (save killed messages to OLDMAIL file) 

YES (YES = save traffic only, NO save all killed messages) 

YES (Generate Service Message during KT) 

YES ( transfer TO field to @ field for message w/numeric TO and blank @) 


55 


56 


YES ( list TRAFFIC zipcode TO fields in ’Mail for’ banner ) 
# ----------- the string sent when he makes a boo-boo ----------- 
*** 29 Unknown command. (Type ’cmds’ and/or *?’ for help) 


Appendix 3: Event File 


The syntax for ROSErver event file entries is: 
type start/end hours command 


where type may be MailBox or DOS; start/end hours are each two digits, 
military time; and command is either a ROSErver or DOS command. 


This is the event file used by the author: 


M 4199 chat off 

M 9513 swap Cl KD6TH * 

M 1721 swap Ci KD6TH * 

M $898 poll C2 KD6TH 

M 9898 make kb7uv list.th list.th 

D $898 del list.th 

D $199 del \roserver\mail\*.~* 

D 2929 fr c: /save 

D 1910 fr c: /save 

D 1419 COPY MAIL.DAT MAIL19.DAT 
D 1919 COPY USER.DAT USER19.DAT 


Appendix 4: Connect Scripts 


This is the calldir.rs file used by the author: 


>1 KD6TH 
(@KD6TH-4 
** EOF 

>2 KD6TH 
%O list.th 
(@KD6TH-4 
&2 

+ MailBox> 
2*** DISCONNECTED 
J 

seimsg top 
B 

ae ae EOF 

>1 K2ULR 
(@KZ2ULR-15 
oe oe ae EOF 


Design of a Next-Generation Packet Network 
Bdale Garbee, NSEUA 


Current amateur packet radio experience centers around 1200 baud half-duplex AFSK 
operation for both local and long-haul use. Technologies are discussed that have the 


potential to effect a fundamentally different environment for 


the next generation of 


packet networking. A preliminary proposal is made for an example network configura- 


tion in the Rocky Mountain Region. 
the new network are discussed. 


Background 


While the existence of 1200 baud half-duplex as a 
defacto modem standard for packet radio has 
undoubtedly proven extremely beneficial to the rapid 
growth of this operating mode, the fact that our 
standard has been 1200-baud has probably caused 
many would-be packeteers from the communications 
and software industries to go look for something 
more exciting to play with. This has probably 
delayed the development of higher-performance 
packet links, since the existing packet user base has 
for the most part appeared content with the status 
quo. 


There is a_ substantial difference in performance 
between’ existing wired networks, and_ the 
technology that we are using on our FF links. So 
substantial, in fact, as to make the applications 
possible with contemporary packet radio qualitatively 
different from those possible on commercial and 
academic networks. In particular, we have for the 
most part limited ourselves to remote login, file 
transfer, and electronic mail capabilities. 


As a group, we have become so accustomed to 1200- 
baud operation, that there now exists a substantial 
mental hurdle to be overcome before any real 
advancement can be made in packet radio’s future. 
We need to open our minds to the possibilities that 
exist with technology that is available today. We 
also need to break the traditional "I'll do it my way" 
reputation that surrounds amateur radio, and learn 
how to work together if we intend to plan and build 
substantially faster networking resources for amateur 
use worldwide. 


Goals 


lf we are to discuss methods for dramatically 
increasing the throughput of packet radio networks, 
it is important for us to have a consistent vision of 
what our goals are. When we are evaluating the 


Applications, ramifications, and problems facing 


potential impact of any _ specific change or 
improvement in our network, we must do so with 
clear knowledge of what we are trying to achieve. 


The most significant reason for wanting to increase 
the speed of our networks is the potential for 
experiencing qualitatively different, really exciting 
applications. One of the problems with our current 
1200-baud technology is that interactive applications 
are slow. This leads us to speak of how 
inappropriate packet radio is for keyboard to 
keyboard QSO’s, and to talk about how wonderful 
background tasks like electronic mail are. In reality, 
we are first and foremost amateur radio operators, 
and that tends to imply that we like to be 
communicators. For many hams, communication 
equates with ‘live and direct", real-time radio 
communications. 


Many of the modes we already enjoy in amateur 
radio have digitally oriented counterparts that we can 
and should explore. Amateur TV, or fast-scan, 
enthusiasts might enjoy a network of live HDTV 
transmissions, all running on suitably fast shared 
digital backbones. Repeater cross links might 
become much more common with higher fidelity 
through application of digital voice transmission over 
the same shared digital network. 


But even if all we can envision is the same set of 
tasks that we perform with packet radio today, 
wouldn't it be neat to have them run 50, 100, or even 
1000 times faster? 


Technology 


lf we are going to make any qualitative difference in 
packet radio operation, we will need to migrate to 
higher speed modem and radio technology. A lot of 
work has been underway in this area in the last year 
that is worth reviewing. 


Perhaps the most widely publicized project for higher- 
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speed packet links has been the TAPR development 
project aimed at producing a 9600-baud direct FSK 
packet modem and radio combination. First unveiled 
at the Dayton Hamvention, the initial units promise 
black box operation, with HDLC data in and out on 
one side (or RS-232 with an optional built-in TNC 
board), and an antenna connector on the other side 
for 2 meter operation. Compatible with the KONG 
design TAPR has offered in kit form, and which has 
formed the basis of at least one commercial offering, 
the TAPR unit is destined to set a new standard for 
‘low-end’ packet radio operation. If operated in 
conjunction with a full-duplex digital repeater, 9600 
baud can form the basis of a metropolitan packet 
channel that will provide substantially improved 
performance with existing 1200-baud applications. 


The WA4DSY 56 kilobit modem design has seen 
gradually increasing acceptance in the last year. Part 
of the reason this modem has not seen wider use 
(also true of the KONG 9600 baud design, and a 
fundamental driving force in the TAPR 9600 baud 
project) is that it is not a complete, turnkey solution. 
In order to put a 56kb station on the air, one needed 
to be willing to modify TNC-2 hardware or experiment 
with PC plug-in cards to get a digital data stream, and 
then had to locate and purchase an_ external 
transverter to move the modem’s output from the 
28Mhz region to some frequency of local use, such 
as 220Mhz or 430Mhz, While none of these problems 
are insurmountable (witness the number of stations 
on the air in Georgia and elsewhere!), they have 
undoubtedly hindered widespread use of this 
modem design. The prospects for this unit will 
improve with the availability of other hardware that 
will be described shortly. 


The development effort that is likely to have the most 
significant impact on packet radio in the near term is 
the N6GN project to design RF modems (or true 
"packet radios") for the 900Mhz and 1.2Ghz band, 
that provide 250 kilobits per second using direct FSK. 
With an estimated parts cost of under $200 per unit, 
these may well be a good choice for our next long- 
haul backbone step. And eventually, they show 
great promise as the technology of choice for end- 
user connection to the network. By the time this 
paper is published, prototype units should be in the 
demonstration and testing phase. 


When we are investigating backbone links, another 
project worth knowing about is another that N6GN 
has been working on. With nudging from NSEUA, 
N6RCE, and others, the design of a 10Ghz 
microwave digital link, using cheap surplus 


gunnplexer modules, and providing data rates from 1 
to 10 megabits per second, is now in the PC Board 
layout phase. Prototypes were shown at the Dayton 
Hamvention in April 1989, operating at 1Mbps, and 
work is progressing on development of kits for 
proliferation of this technology. Microwave links are 
particularly attractive for backbones, because of the 
relatively low power levels required, the availability of 
very large amounts of system gain with moderately 
sized antennas (dishes), the fundamentally point-to- 
point nature of the technology, and the resulting 
possibility of frequency reuse. Whenever the 
geography and environment allow, use of microwave 
bands for amateur packet radio backbone links 
should be strongly encouraged. 


Now that we've talked about all this wonderful RF 
gear that’s just around the corner, and which can 
provide substantially faster raw data link speeds, how 
do we generate and accept bits that fast? It’s a 
combination of hardware evolution, and software 
innovation. In the digital hardware arena, there are 
two projects underway that are worthy of note. 


Two years ago, the PS-186 packet switch board was 
unveiled. For a variety of unfortunate reasons, the 
units have never been produced. That is about to 
change. AEA is expected to be shipping units in the 
very near future, and a port of the KA9Q software is 
underway by NSEUA. Bluntly, the PS-186 is the most 
likely packet switch candidate for the next round of 
packet network improvements. Based around an 
80186, the unit provides 4 high speed HDLC channels 
with full DMA, capable of over 1 Mbps per channel, 
full duplex. In addition, the unit draws very little 
power, and includes features like a ‘“firecode’ reset 
circuit for "pushing the big red button" remotely, and 
it's single-board configuration makes it ideally suited 
for mountaintop packet switch operation. 


Simultaneously, Mike Chepponis K3MC has 
completed the design of a plug-n card for the IBM PC 
and compatibles that will provide two or more 
channels of fast HDLC, capable at least of handling 
the N6GN 250kbps radios. Sporting an onboard V40 
microprocessor, the design allows migration of part 
of the networking code onto the card and away from 
the main computer, making for faster and more 
efficient network operation. In addition, it appears 
that it will be possible for this unit to run in a 
standalone configuration, providing some subset of 
the PS-186 functionality when less capability is 
required for packet switch sites. 


With these two pieces of digital hardware, arriving at 
almost exactly the same time as the N6GN faster RF 


solutions, we are suddenly faced with a complete 
hardware solution for faster packet operation at both 
the end user and network backbone levels! And 
most excitingly, the cost of a PS-186 based packet 
switch site with a 900Mhz/1.2Ghz or 10Ghz RF setup 
for the backbone link(s), and one or more channels 
of contemporary or new-technology RF for local 
access, has the potential to cost about the same 
number of dollars as a site with an equivalent number 
of ports of 1200-baud TNC, firmware, and commercial 
FM radios! 


It is probably not surprising that most of the high- 
performance digital development is happening hand- 
in-hand with creation of device drivers and improved 
networking capabilities in the KA9Q TCP/IP software 
implementation. To date, the KA9Q package is the 
only software that has been available to test packet 
hardware at speeds faster than the 9600 baud range. 
This is in part due to the ready availability of full 
source code. But even more importantly, the TCP/IP 
protocol suite is a mature set of protocols, that have 
evolved in an environment of heterogeneous 
computer systems connected by a wide assortment 
of networking technologies at various speeds. Since 
this is a pretty accurate description of the emerging 
amateur packet network, we should not be surprised 
that the TCP/IP protocols also work well in our 
environment! Particularly since the KASQ package 
provides all of the common AX.25_ functionality, 
compatibility with existing NET/ROM networks, and a 
fairly reasonable programmer's _ interface for 
development of new applications. At least initially, 
the KASQ package will be the software of choice for 
operating on our next generation network. 


Proposal 


In order to illustrate how we might combine the 
emerging hardware and software technologies to the 
problem of building our next generation "dream 
network", let's take a look at a real situation. Without 
being overly specific and detailed, here is a proposal 
that will be made for the Rocky Mountain Region, 
centered around Colorado. 


The existing packet backbone is composed almost 
entirely of NET/ROM compatible nodes operating 
either single-ported on 145.01 Mhz, or in some cases 
dual-ported to 446.8 Mhz as a backbone frequency. 
There is a dense population concentration along the 
Colorado front range of the Rocky Mountains, 
including relatively isolated RF communities in 
Denver, Colorado Springs, Northern Colorado around 
Fort Collins, and so forth. The average distance 
between these clusters of humanity is between 40 
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and 50 miles. To the west, there are scattered 
clusters of activity in and around the high-altitude ski 
country, and at Grand Junction on the western edge 
of the state. Paths between switch sites on the 
East/West backbones are frequently far enough 
apart to preclude easy application of microwave 
technology such as the N6GN 10Ghz design. To the 
South, a couple of long hops connect New Mexico 
and Texas, and to the North, very reasonable paths 
connect into Wyoming. 


Two problems then exist. One is fitting technologies 
to needs, and sequencing changes to achieve 
maximum benefit early in the process. The second is 
gaining sufficient support (monetary, political, and 
volunteer labor) to make the plan succeed. This is a 
tough battle, particularly when the technical solution 
proposed is esoteric enough (at least compared to 
contemporary amateur packet technology) to seem 
“sCary’. 


First, existing relay sites should have their digital 
hardware replaced with PS-186 boards. Equipped 
with a standalone version of the KA9Q NOS 
software, these boards will interoperate with the 
existing NET/ROM backbone, and provide a 
foundation for building better links. 


Second, links along the Front Range that are of 
moderate distance should be upgraded to 1 Mbps 
links on 10Ghz, if possible in parallel with the existing 
1200 baud technology until the new links are 
Stabilized and proven. Because there is a potential 
for tremendous data transfer needs among the high 
population densities in this area, the technology 
providing maximum data rate over point-to-point links 
is the obvious choice. 


Third, the sites along the East/West paths and to the 
South, where distances are perhaps too great for 
reliable 10Ghz operation, should be equipped with 
1.2Ghz N6GN units at 250kbps. We choose 1.2Ghz 
over 900Mhz primarily because part of Colorado is 
included in the area closed to amateur use of the 
900Mhz band. These radios, combined with gain 
antennas (perhaps using power splitters or duplicated 
TX gain blocks for multiple point to point links), have 
the potential of operating reliably over the path 
lengths involved (on the order of a hundred miles. 
between 14,000 foot peaks...). The 10Ghz 
technology is favored because of cost (less than 
$100 parts cost per end including a 2-foot dish!), deta 
rate, and fundamental point to point operation... but 
there are undoubtedly locations where dishes or 
other microwave bits and pieces will not be 
appropriate. 
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Simultaneously with installation of these faster 
backbone links, we should investigate better local 
access ports. The advantages of full duplex 
repeaters for true CSMA/CD operation have been 
widely discussed. In Colorado, a mixture of 1200 
baud and 9600 baud full duplex ports is probably a 
good initial step, with 56kb cross-band full duplex 
worthy of consideration. 


Making It Happen 


Before we go out and start building things, we ought 
to be prepared to spend some time assessing the 
current usage patterns on our existing packet 
network links. As appealing as it might seem at times, 
removing an existing facility to make room for “bigger 
and better" is rarely a wise move. We need to make 
sure that any new facility we install, and any facility 
that we upgrade, provides a growth path for existing 
users. 


lf we are going to successfully upgrade our major 
packet facilities to a substantially higher level of 
performance, we're going to need to enlist all the help 
we can get. In particular, some energy should be 
expended investigating applications that are outside 
of the traditional uses of packet radio. Armed with 
ideas, we can then approach groups that are not 
known for being strong packet supporters, with 
some hope of gaining cooperation and support. 


The N6GN 10Ghz microwave links have as an option 
an audio sub-channel, that might be used to provide 
phone patch capabilities to a remote repeater site that 
we want to equip with fast links. The expansion bus 
of the PS-186 might be utilized to support custom 
hardware providing remote control and telemetry for 
existing RF gear at a switch site. I'm sure you can 
think of other such possibilities. 


lt is a fact of life that many of the best RF sites for 
high speed packet backbone hardware are currently 
controlled by FM repeater or fast-scan video user 
groups. The key to gaining access to these sites is 
finding ways to add value to their operation when 
they allow us rack and tower space. In Colorado, the 
emerging relationship between the Rocky Mountain 
Packet Radio Association (RMPRA), and the Pike's 
Peak FM Association (PPFMA) is an example of how 
this can really work. 


Keeping It Happening 


Even if we do our homework, plan our links carefully, 
and get as many groups as possible involved in 
implementing our network, there are still several 


problems that can crop up that deserve discussion. 


An initial burst of enthusiasm followed by a loss of 
interest before any milestones are reached can be a 
real problem. The best way to counter this 
phenomena is to sequence the installation of switch 
and local access improvements such that high 
visibility sites are upgraded first. This way, the 
maximum number of folks will have a chance to 
experience the improvements, and get excited about 
the possibilities. And if you can grow the excitement 
by pulling in more and more new folks to help with 
the effort, so much the better! 


Despite our tradition in the amateur hobby of 
working with gentleman’s agreements, we need to 
consider putting some of the decisions made, 
particularly between groups that don’t have a history 
of beneficial cooperation, into writing. This will help 
to make sure that the loss of a key member of the 
effort won't leave the two groups wondering what 
"the other guys” were supposed to do, or even worse 
leave two groups that won't speak to each other! 
The things that most need to be documented are 
who is going to pay for and implement each piece of 
the network, and what their expected schedule is. 


And finally, as WOYNE has been heard to question 
on innumerable occasions: "Who's going to take 
care of all this stuff?" It’s easy to find people to drive 
half a day, climb a mountain, and install a new piece 
of gear. It’s not too hard getting those folks or folks 
like them out the first or second time something 
breaks or gets hit by lightning. But what happens a 
year or two down the road when the initial support 
groups have all burned out and gone back to 
chasing 40m DX, or rag-chewing on 80m? 
Considering carefully how to handle long-term 
upkeep of our networking facilities is a need that 
cannot be overstated. If we're going to go to the 
trouble of building a real network, we need to be able 
to maintain it! 


Conclusion 


Sitting back and thinking about all of the issues that 
surround the design, acquisition, installation, and 
maintenance of a next-generation amateur packet 
radio network may make the problems seem to be 
insurmountable. There are, in fact, some really 
difficult questions that need to be answered. But | 
hope the message conveyed by this paper is that 
none of the problems are impossible to solve! We 
can, and should, strive for a major upgrade in quality 
and performance of our packet network. 


I've talked briefly about some of the technologies 
that might play a part in building our “dream 
network". It seems particularly exciting that the PS- 
186, the K3MC fast I/O card, and really fast RF 
hardware by N6GN are all coming together at about 
the same time. We've asked many times "where is my 
high-speed packet?" The answer is that it’s here, it's 
now, and we no longer have any excuses for not 
improving our networks! 


lt is hoped that by the time this paper is published, 
further details will have been worked out regarding 
the development of a faster packet network in 
Colorado. The author would be pleased to hear from 
individuals involved in similar efforts elsewhere. 
Electronic mail is preferred, bdale@col.hp.com on the 
Internet, 76430,3323 on Compuserve, or NSEUA @ 
KAOWIE via packet BBS. 
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ABSTRACT 


A software package is described that interfaces a Terminal Node Controller (TNC) 
to computer (host) running the 4.2 BSD Unix Operating System, over a_ serial line. 
An OM-shell is opened for every incoming AX.25 connection to the TNC so that the 
remote user needs only a terminal to log in a HAM _ devoted environment. Some 
utilities are then offered by the OM-shell and among others the possibility to issue 
telnet-like commands to the hosts and gateways of the Department LAN. 


WHY WE BUILT IT 


The increasing appeal of the KA9Q TCP/IP package is mainly due to the _ capability 
of performing Computer Networking in place of the primitive Terminal Networking. 
The implementation of the major ARPA _ intemet protocols over IP in this package 
allows AX.25 users to connect to remote hosts over a wide number of computer 
networks by performing end to end automatic functions. 


Also in our country there is a trend to encourage strongly the use of _ this 
protocol, and IP reserved channels and repeaters are already in use. Unfortunately, 
the channel load resulting from higher level protocols’ like this may be high, and 
for some applications over a low speed (i.e., 1200 baud) channel it may become 
overwhelming. 

We refer for example to a popular application like a remote-terminal session that is 
established with the telnet command in the ARPA internet protocol suite. 


Some of us, OM and at the same _ time researchers at DIST, like to have the 

possibility to log in hosts of the Department LAN over the radio channel, and _ the 
immediate solution was to connect a KA9Q gateway between the TNC and the Ethernet 
cable. 
It was easy to note that the 1200 baud speed allowed by the UHF voice transceiver was 
only a dream... In fact, some problems arise from this easy solution. The main one is 
due to the difference in bandwidth between the two networks. The host drives a high 
speed (Ethernet) line and for every message it sends, it expects to receive an ack 
for a certain time. This time is short if compared with the time needed for the 
radio channel to route the message to the remote station (the radio channel at this 
speed is about ten thousand times slower than Ethernet). 
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For this reason, the host sends several times the same message always expecting an 
ack and stopping the turnover of the _ half-duplex channel. Only when _ the 
sequence of repeated messages ends, the radio channel reverses’ its direction 
and the ack sequence is eventually received from the host. This fact was already 
noted in [1]. 

Just sometimes, when the Ethernet traffic is high, the delay between’ two successive 
retransmissions allows the turnover of the radio channel, and this expedites the 
exchange. Only for few implementations of TCP, once the connection has been 
established, the system on the Ethernet side learns’ its correct timeout. 


The solution would be to change the timing of the various ARPA internet 
protocols (ICMP, UDP, TCP...) by every host: in presence of packets routed to. the 
radio gateway, the equivalent of the AX.25 FRACK time should be appropriately 
set. This may be cumbersome or impossible on a wide LAN. On the other way, what we 
needed was merely an _ error free connection, and so we decided the AX.25 
protocol was enough for a comfortable remote-terminal session. 


WHAT THE SOLUTION 


The idea was then to write a package, running on a_ host (specifically a 
Microvax II) connected to the Department LAN, capable of managing the TNC 
through a RS232_ serial port and offering the possibility to open something like a 
shell forthe terminal active on the other side of the radio channel. 


We got our goal by implementing a Radioserver, supported by the Unix 4.2 BSD 
Operating System, capable of managing multiple connections between the TNC and 
remote stations. The user interface is a_ shell offering the possibility to issue some 
commands to the host. 


We never forget we are firstly OM, and so an "OM-shell" was created to satisfy 
the local community more interested to common HAM applications rather than to 
the direct access to the Unix resources. 


The package was provided with some administrative and statistic facilities 
like user registration, command history and activity tracing. Mail box, database 
of software utilities, BBS service and similar are then supported by the OM-shell. 
Also a game session is provided. 


For the hardware support, an AEA TNC was chosen for its possibility to 

dialogue with the host in "“host-mode", a non verbose interface providing greater 
direct control over the TNC with a communication based on character blocks [2]. 
In this way, we could simplify the transfer and subsequent encoding and 
decoding of commands and informations. The host mode lets the TNC _ fully manage 
the AX.25 protocol (particularly retransmission for error recovery), so we did not 
need to implement it in our package. 


The server is made up by concurrent processes communicating with "sockets". 
The socket, that looks like a file shared between different processes, is the basic 
building block within Unix communications domains. Domain is an abstraction 
introduced to bundle common propertics of communicating processes [3]. 
The socket is proper of the BSD Unix version and it offers an easy tool for real 
interprocess communication. 
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HOW THE PROGRAM LOOKS 
For a concise description of the package we refer to figure 1. The following 


processes are always active: The Supervisor, the RS232_reader, the RS232_writer, the 
PTIP daemon. The others are activated upon an incoming call. 





| -shell 


OM-shell 
/ C omshe — 


RS232_ reader > 








RS_PTIP_socket | 


Senial line device 
| NETWORK. socket | 





RS232 writer 





PTIP daemon 


PTIP_user_socket 





Fig. 1 


The RS232_ reader is interfaced to the input port device (RS232 serial interface) 
and it disassembles the received character blocks out of the “host mode" format. 
This process also ensures transparency by unstuffing of the DLE characters. 
The incoming packets are then placed in the RS_socket or in the RS_PTIP_socket 
according to the stream number. (The AEA TNC accepts a maximum of 10 users, i.e. 10 
stream numbers). 


The RS232_ writer acts in the same way, but in the other direction. It reads 
from the RS socket or from the RS_PTIP_socket data structures and assembles the 
host format packets to the TNC, 


The Supervisor is the parent originating all other processes; after initialization, 
it keeps a record of the active connections in a connection table, manages the 
packets containing control data, and kills the child processes related to disconnected 
links. 


Besides the above mentioned services, the OM-shell may connect the RS_socket 


with a NETWORK socket. In other words, the OM- shell may activate the gateway 
function between AX.25 and the LAN. Every connected user disposes of a OM-shell. 
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In this way, it is possible for the authorized users to connect to the desired host with 
a telnet-like command. After this connection, the user holds the Unix shell of _ the 
connected host. 


A user program can access the Radioserver using the PTIP_USER_socket: a 

function library has been developed containing primitives that are useful to 
manage the data exchange between’ the user and the PTIP daemon process. Thus, 
the user program is allowed to manage the TNC in the _ issuing of outgoing 
connections (some of the virtual channels of the TNC are reserved for outgoing 
connections for the possibility of automatic mail forwarding). 
With this library, several utilitics have been implemented. Among _ these are 
mail forwarding with WORLI- rules, and a terminal emulator that allows an 
authorized user logged on a LAN's host to access the TNC as if it were in the normal 
mode. It is so possible to connect AX.25 stations operating on the radio channel, to 
monitor the channel, and to temporarily change the TNC parameters, disposing 
of every TNC command. 


The implementation of further utilities like file transfer commands or others 
was not justified because the superiority of those existing in the KA9Q _ software. 
Actually, even the implementation of this. telnet-like utility might appear 
needless, but the package has been now "on the air" for two years and many 
amateurs are using it daily. More than 5000 connections at this time demonstrate 


some usefulness of this work. 


CONCLUSIONS 


An interface between a TNC and Unix environment has been described. The 
aim was not to substitute the use of existing network IP based protocols but to offer 
an easy tool to communicate with a computer running the Unix O.S. using a radio 
channel and AX.25. At this level, a set of selected utilities proper of the Unix 
environment are then easily accessible. 
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A STUDY OF 
HIGH SPEED PACKET RADIO 


Roy E. Gould, N5SRG 
4752 DeBeers Drive 
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ABSTRACT 


Some of the possible transmission methods that could be used in the high 
speed packet radio network are discussed and analyzed. The conclusion is 
reached that a good approach is to directly FSK the RF carrier at 38.4 Kbaud. A 
19@@ kHz RF bandwidth channel above 228 MHz should be used and a scrambler should 
not be used. The radio should be designed using modern IC’s so that a simple 
and relatively inexpensive yet high performance radio results. 


INTRODUCTION 


A major advancement that must be made if packet radio is to reach its 
potential is the development and operation of a high speed network ocperating on 
the vhf and uhf bands that enables veru fast and highly reliable digital 
information transfer in the local area as well as between widely separated 
points. Ideally, this network should be fast enough that transferring 
information between packet bulletin board systems or between TCP/IP stations 
will not adversely slow down QS0’s between individual operators. As pointed out 
by Bdale Garbee in his paper "MORE AND FASTER BITS" (Ref 1) it should be so fast 
that such things as digitized voice and computer graphics become practical. Most 
likelu, the applications that become practical because of the high speed and 
high throughput of the network will grow to the point that even the highest 
channel capacity will be fully utilized, at least part of the time. While there 
will most likely always be a place for low speed packet, there seems little 
point in the long run in having a tlocal area network running at a different 
speed than the “backbone”. They should both run at the same high speed. 


Packet radio is still in its infancy and the decisions we make today 
regarding transmission standards will have a far reaching influence that will be 
difficult to erase. Once a network is built using a particular standard it will 
be very difficult to change even if some new method offers greatly increased 
performance. Therefore, it is important to take the time to figure out what the 
best approach is and to get started on the right foot. It will be more 
efficient to 90 directly to the ultimate standard rather than taking several 
intermediate steps requiring rebuilding the network several times. It is 
important to design the network from the beginning to have as high a 
transmission speed as practical while at the same time taking into account the 
difficulty and cost of building the network and with the view in mind that it 
will eventually replace the current 1200 baud system. I hope that this paper 
will give you some ideas and that it will help to formulate a common standard 
that all Amateurs can work from and to which manufacturers can build equipment 
so that the next step in building the packet network can take piace. 
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HOW PACKET IS TRANSMITTED 


Understanding the way in which packet radia signals are transmitted is 
essential for understanding what 15 needed ina packet radia link. Three 
important attributes of a packet signal are 1) the bits are sent sunchroncusly, 
2) Non Return to Zero Inverted (NRZI) encoding is used, and 4) bit stuffing is 
used. 


Packet radio bit streams are transmitted sunchronously. There are no start 
and stop bits associated with each byte of information as is done con RITY or on 
the RS-232 communications line between your TNC and computer. If the receiver 
dees not lose lock then start or stop bits are not necessaru to maintain 
sunchronization with the bit stream. A series of flags at the beginning of the 
transmission is used to establish the initial byte sunchronizaticn. 


The packet bit stream is sent using Non Return to Zero Inverted encoding. 
A logic one is sent bu not changing state anda logic zero is sent by changing 
state. This means that when a series of ones 15 sent there is no change in the 
signal. When a series of zero’s is sent, the state changes for each zero. One 
important implication of NRZI encoding 15S that mark and space lose their 
significance. It is only the change in state that is important. No change 
means "1" and a change means “"@", The receiving equipment must remember what 
the last state was so that it can compare the last state with the current state 
so that it can determine whether the current state is a one or a zeroa. 


Bit stuffing is used to insure that the flag will be unique and toa make 
sure that the signal cannot stay in one state for an extended time so that the 
receiver will see a transition in state often enough to maintain lock on the bit 
stream. Except when sending flags, if five logic ones occur in sequence, the 
transmitter "stuffs" in a logic zero before the next bit is transmitted. The 
use of zero stuffing insures that inside the packet bit stream the longest 
string of logic ones that can occur is five. The flag is 7E Hex. Therefore, 
sending the flag requires the transmission of six logic ones in a row. The use 
of the combination of NRZI and bit stuffing insures that the signal will not 
stay in the same state for very long so that a data clack can be readily derived 
from the signal. This also, in effect, scrambles the signal. It is not clear 
to me that any further scrambling of a packet signal as is done in the G3RUH and 
the Heatherington modems actually does anything benificial. 


The highest frequency that must be transmitted occurs when a string cf NRZ! 
zeros 1s transmitted. In this case the state changes at each bit. This means 
that the highest keying frequency is5 one half the baud. For example, for a 
signal at 43@@ baud, the highest frequency that must be transmitted is 7488 Hz 
if the harmonics of the square wave keying signal are filtered off. That the 
baud 1s double the highest frequency transmitted 1s consistent with the 
Nyquist-Shannon theorem. tpage 129 of Ref 2) 


_EFFICIEN 





It is helpful to have a method for comparing the relative efficiency of 
various transmission methods so that a judgement can be made as to which method 
makes the best use of the spectrum. One way to do this is to compare the 
Spectral Efficiency {bits per second being transmitted per Hz of bandwidth 
required for the transmission. i.e (bits/sec)/Hz) of the methods being 
considered (see pages 304 & 394 of Ref 3). There are two types of bandwidth that 
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could be used: 1) baseband or 2) RF bandwidth. Baseband is the bandwidth of the 
system from the input to the transmitter to the detected signal output, while 
the RF bandwidth is the bandwidth of the RF signal itself. It is important to 
define which type of bandwidth is being used in a particular calculation of 
spectral efficiency. 


One of the more efficient methods used on commercial satellite channels 
achieves 4.5 bits/s per Hz of baseband bandwidth in practice ‘see TABLE 2.15 of 
Ref 4). An interesting question to ask is "how good is the common packet radio 
transmission using the Bell 2@2 modem standard that everyone uses for 17@8@ baud 
transmissions on 2-meters 7" A lock at Fig Za in the paper "960@ Baud Packet 
Radio Modem Design" found in Ref 1 indicates that the baseband bandwidth of a 
NBFM radio link could be conservatively called 5 kHz. Using this number’ the 
spectral efficiency of the 2-m transmission is computed to be @.24 bits/sec per 
Hz. The commercial satellite channel with its throughput of 4.5 bits/s per Hz 
passes information 18 times faster for a given bandwidth than we do on our 
Z2-meter packet radio channel' There is a lot of room for improvement here' 


MULTI-RIT TRANSMISSION 


Amateurs are accustomed to thinking of sending digital information one bit 
at a time. That 1s the way Morse code and the teletype machine works. Packet 
radio as currently used sends one bit at a time and so does your computer to INC 
link when it communicates over the RS-232 cable. But that is not the only way 
that things can be done. In the commercial satellite world, one bit at a time 
is usually not done and is iin fact not allowed by the FCC rules for high 
capacity channels because it 1s too wasteful of spectrum. (see page 1849 of Ref 
4) It is also a matter of economics. The communication satellite has a limited 
amount of spectrum available and using it efficiently makes more money for the 
satellite operator. 


A method that is often used to convert an existing analog link to a digital 
link 1s to use a scheme such as this: The signal is transmitted using four 
different fixed carrier shifts. The signal is detected using the same 
discriminator that would normally be used for ordinary FM detection. A set of 
comparators followed by logic is used to determine which of the four frequencies 
is being transmitted. Since it takes four different states to define the state 
of two bits, each of these frequencies defines a unique state of the two bits. 
Each signaling interval transmitted is equivalent to transmitting two bits, 
yielding a theoretical increase in transmission speed of two. 


Even though there are techniques for sending more than one bit at a time, 
they are probably more complex than can be Justified at the present state of 
development of Amateur digital communication art. It seems relatively easy to 
increase the efficiency of Amateur packet transmissions to 1.0 or to even 2Z2.4@ 
bits/s per Hz of baseband bandwidth without resorting to multiple bit 
transmission. This is an improvement of 4 to 8 over current practice on 2Z-m. 
The additional complications and expense of reaching transmission efficiencies 
greater than 2 bits/s per Hz do not seem justified at this stage of development. 
However, it should not be forgotten that it is possible to increase the spectral 
efficiencu by transmitting multiple bits per signaling interval if the need 
should arise in the future for more efficient use of the spectrum. 
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SURVEY OF MODULATION METHODS 


According to Ref 3, page [64, there are three attributes of a signal that 
can be modulated -- its amplitude, frequency, and its phase. With the excepticn 
of Morse code which is AM, Radio Amateurs have traditionally used some farm of 
FM for digital communications. There are currently two different ways oaf 
modulating the information onto the RF carrier being used in the packet radio 
world. One of these is to frequency shift key (FSK) the RF carrier directly with 
the packet bit stream. The other 1s to audio frequency shift key (AFSK) an 
audio carrier with the packet bit stream and then to FM the RF carrier with this 
modulated audio carrier. 


sh of the RF Carrier 


The typical 300 baud transmission on 2@-meters in effect modulates the 
packet bit stream directly onto the RF carrier using FSK. This is usually done 
by translating a 2@@-Hz shift AFSK Signal to RF by mixing in a ssb transmitter. 
Even though the signal is coming from a ssb transmitter, the transmitted signal 
15 a FSK signal with a shift of 2@@ Hz that could be detected directly by an FM 
receiver instead of the normally used ssb receiver. If the signal was detected 
by an FM receiver, the packet bit stream could be taken directlu from the FM 
detector. The theoretical spectrum generated by this signal shown in TABLE-1 
indicates that the RF bandwidth required by this signal is a little more than 
twice the baud. Bandwidth is based upon the definition of bandwidth given in 
the FCC rules which says that bandwidth 1s "The width of a frequency band 
outside of which the mean power of the total emission, is attenuated at least 74 
GP below the mean power of the total emission, including allowances far 
transmitter drift or Doppler shift." (97.2a8, Ref 5) The amplitude shown in 
TABLE-1 is the power level of the sideband below the total power in the 
emission. 


FM by a FSK Audio Tone 


Even though the 1200 baud signal used on ?-meters begins in a similar 
way to that on 2@-m, the transmitted RF signal is quite different. The packet 
bit stream first frequency shift keus an audio carrier between the 1700 and 72799 
Hz Bell 2@2 standard tones. Then this audio signal drives the FM modulator of 
an FM transmitter i.e. the FSK modulated audio carrier is FM’ed onto the RF 
carrier. When received bu an FM receiver, the modulated audio carrier (not the 
bit stream itself) is recovered by the discriminator and must be detected one 
more time by the FSK demodulator in the FNC to recover the packet bit stream. 


The main advantage of this method is that it allows an ordinary NBFM voice 
radio to be used for packet radio. Unfortunately, as the theoretical spectrum 
for this signal presented in TABLE-2 shows, it does not make good use of the RF 
spectrum. Applying the -26 dB FCC bandwidth rule indicates that about 9498 Hz 
of RF bandwidth is needed to transmit at 1200 bits/s for a bandwidth efficiency 
of @.125 bits/s per Hz of RF bandwidth. This is a conservative estimate because 
many stations are deviating more than 2280 Hz. 


The amplitude of the sidebands shown in TABLE-2 have been reduced 3 dB 
because it has been assumed that an equal number of 1200 and 22@@ Hz bursts are 
being sent. Amplitude as used in TABLE-2 is the average power of the sideband 
below the total power in the emission. 
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TABLE-1 TABLE-2 


Theoretical RF Specturm of a Theoretical RF Spectrum of a 
308 baud, 280 Hz shift FSK Signal 1208 baud Signal Sending Bell 282 
Transmitting NRZI zeros. Tones Deviating 2.2 kHz 
Sideband Pair Amplitude (dB) Sideband Pair Amplitude (dB) 
carrier 41,16 carrier -I2e1 
+/- 158 Hz -8.1 +/—- 12006 Hz =—Jel 
+/- 380 Hz -21.4 +/-— 2288 Hz -10.1 
+/- 450 Hz —33.2 +/-— 2480 Hz -135.08 
+/-— 3602 Hz -22.6 
no keying filter used, +/-— 4408 Hz ~Ziwt 
deviation = (4/pi) * 108 Hz +/- 4890 Hz a I | 
+/— $830 Hz -49.5 
+/— 65600 Hz -3fs1 


The 300 baud ssb method used on 2@-m makes good use of the spectrum and has 
an efficiency of nearly @.5 bits/s per Hz of RF bandwidth. Contrast this with 
the 1280 baud Bell 202 modem method used on 2-m which has an efficiency of only 
about @.125 bits/s per Hz of RF bandwidth. If we used the 2@-m type of 
transmission oon vhf or uhf we would realize a substantial improvement in RF 
bandwidth utilization. 


The Heatherington RF Modem 


The transmission methods dicussed so far have employed FSK of either 
the RF carrier or an audio carrier by the packet bit stream. But there are other 
ways to transmit the packet signal. One of these is used in the RF Modem 
designed by Dale Heatherington (WASDSY) which is described beginning on page 6a 
of Ref-6. It can run bauds ranging from 96@@ to 565,000. It is called an “RF 
modem" because its radio input and output is at 29 MHz and its data input and 
output is the packet bit stream. A linear transverter must be used with it to 
generate RF output on the band of interest. Good use 1s made of the spectrum 
since an RF bandwidth of 7@ kHz is required to transmit 56 kbits/s. This is a RF 
bandwidth spectral efficiency of @.8 bits/s per Hz. 


The modulation used is a bandwidth limited form of Minimum Shift Keying 
(MSK). (see page 195, Ref 2 for a description of MSK) The carrier phase is 
shifted plus or minus 99 degrees for each bit. The modulator synthesizes the 
cignal from aquadrature components and is therefore very versatile in the 
waveforms it can produce. A scrambler 15 used to improve clocking and to make 
the modulated signal appear to be noise. It appears to be a versatile system 
that can operate at the highest legal baud. The main disadvantage 15 that it 1s 
relatively expensive because it requires both the RF modem and aie linear 
transverter to make up a complete system. 


A question that might be asked is “how well could we do if we directiy FSK 
the RF carrier with the 56 Kbaud packet bit stream?". In an attempt to answer 
this question, the restraint is imposed that a linear FM modulator is used and 
that the packet bit stream passes through a low pass keying filter with a gain 
of —? dB at 278 kHz. The keying filter removes the harmonics of the square wave 
keying signal and reduces the amplitude of the fundamental of this keying signal 
to 1. This helps to reduce the amplitude of the sidebands above the second 
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Sideband to an acceptabie levei. 


The theoretical spectrum of such a signal for three different shifts is 
shown in TABLE-3. It appears that the optimum shift is about 28 kHz. At this 
shift the 180 kHz bandwidth limitation imposed by the FCC rules for packet 
signals above 727@ MHz can be met while at the same time utilizing as wide as 
possible shift for the best signal to noise ratio. 


TABLE-3 


Theoretical RF Spectrum of a 56 Kbaud FSK Signal 
Transmitting NRZI Zeros (LP Keying Filter Used) 


Amplitude (dB) for shift of 


Sideband Pair 14 kHz 28 kHz 56 kHz 
carrier -@.1 -9.5 —2.5 
+/—- 28 kHz -18.1 -12.3 =F ot 
+/- 56 kHz -42?.,1 -30.2 -{8.7 
+/- 84 kHz -69./ -51.9 —354.1 


It appears to me that unless the Heatherington sustem achieves a 
Significant improvement in reception under weak signal conditions that its 
complexity and high cost cannot be justified when compared to a system using 
direct FSK of the RF carrier. 


Amplitude Modulation 


From a technical point of view, amplitude modulation could be used in 
a packet radio link and does have some advantages. Note that the FCC rules do 
not permit AM in a telegraphy link designed for automatic reception of the 
signal. Consider for a moment the problem of achieving 19.2 Kbaud on 2? meters 
where the FCC rules limit the bandwidth to 20 kHz. One way to do this is to use 
AM. A low pass filter with 2 dB attenuation at 96@@ Hz is required to attenuate 
the high frequencu components from the keying signal and to prevent 
overmodulation. In the worst case condition of sending a string of NRZI zercs, 
the RF signal would be 1@@ percent modulated with a 946@@ Hz sine wave. The 
spectrum for this signal has only three components - the carrier and two 
sidebands. fhe carrier amplitude is -1.8 dB below the mean power of the total 
emission and the two sidebands which are spaced at +/-— 94@0 Hz from the carrier 
are down -7.8 dB. The bandwidth of the signal is 19.2? kHz so the bandwidth 
requirement has been met. 


A radio link using AM should work well, especially when used in a VHF or 
UHF radio link. AM has proven effective for many yvears for the transmission of 
Morse code on the low bands. And the fact that it can be received by machines 
has been demonstrated by the many amateurs who have used various types of 
equipment currently available to copy Morse off the air and display the text oan 
the computer screen. AM has the disadvantage that it is somewhat more difficult 
to produce a 100 percent modulated signal as compared to FM. It has the 
advantage that it can be easily detected at higher IF frequencies such as 18.7 
MHz whereas NRFM cannot. Use of AM would reduce heating of the final amplifier. 
An AM packet radio system could be made to work and would probably work well. 
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A relatively new method of transmission allowed by the FCC rules is 
spread spectrum (SS). The rules explain that SS may be used only above 42@ MHz. 
Only frequency hopping and direct sequence transmissions are authorized. See 
12.3, Ref 3 for a description of SS. A fundamental characteristic of SS is that 
the transmitter’s power is spread over a wide bandwidth and most conventional 
receivers will not even notice that the SS signal is present. It can provide low 
error rates and many stations can use the same channel simultaneously without 
interfering with each other. Sounds like just what we need for packet. 


Sections 5.11.2 through 5.11.6 of Reference 2 discusses many aspects o”% 
using SS in various sorts of multiple access radio links including even a CB 
radio scheme. Some of the advantages listed are (a) immunity to ORM. (b) 
security of information in the channel, ({c) immediate random access to the 
channel by a number of users and (d) graceful degradation of the channel with 
overload. SS might be the ideal way to go in a shared channel packet radio 
Situation, however, this subject requires a considerable amount of research 
beyond that done for this paper to determine if it 1s actually practical. 


CONCLUSIONS 


Operating packet at 1200 baud using Bell 282 tones through NBFM radios 
should be abandoned for all serious packet work. It should be replaced with 
radio links running 38.4 Kbaud or higher. Packet operation must be shifted to 
frequencies above 22@ MHz because the FCC rules do not allow the higher bauds 
below that frequency. Direct FSK of the RF carrier by the packet bit stream 
should be used. The deviation in hertz should be the same as the sending speed 
in baud (modulation index of 1). The transmitter should use a linear true FM 
modulator. A low pass keying filter should be used for bandwidth control. A 
modem 1s not required since a logic level keys the transmitter and a logic level 
comes out of the receiver. The use of a scrambler is not recommended unless it 
can be shown that it actually improves packet radio transmission auality or 
reduces the bandwidth required. 


Operation at 38.4 Kbaud is recommended because the amplitude of the second 
sidebands of an FSK signal sending NRZI zeros with a modulation index of 1 
exceeds -26 dB down. If 38.4 Kbaud is used these second sidebands will he 
spaced at +/- 38.4 kHz from the carrier and will be comfortably within the 188 
kHz bandwidth allowed by the FCC rules. The maximum legal baud of 56 Kbaud is 
only 1.46 times higher than 38.4 Kbaud so this is a reasonable trade-off. 


Because a 39.4 Kbaud packet signal is a wideband signal the receiver can be 
Simpler than a NBFM receiver. It is not necessary to convert down to a low 
frequency IF such as 455 kHz to obtain good FM detection as 15 usually done for 
NBFM. A single conversion receiver to 18.7 MHz will work fine. Frequency 
stability does not have to be as good for the wideband signal as for NEFM. 


One possibility for a receiver is to convert a standard FM broadcast 
receiver. The IF bandwidth of such a receiver is about 258 kHz which 1s wider 
than the ideal bandwidth of somewhat more than 18@@ kHz. The front end, mixer, 
and LO would have to be converted to work at the frequency of interest. A 
connection would have to be made to an appropriate DC coupled output from the FM 
detector. The output from the detector would drive a comparator to produce a 
logic output. While a broadcast receiver might be made to work, this probably 
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is not the best solution. But advantage should be taken of the mass produced and 
inexpensive components such as ceramic IF filters and detector coils for 108.7 
MHz that are manufactured for these receivers. 


There are at least two single chip receiver IC’s available that appear to 
be ideal for application in packet radio receivers: the Motorola MC3354 and the 
Signetics NES@5N. The C3356 is a FSK receiver designed ta operate up to S8G 
Kbaud. The IC contains a complete receiver with mixer, oscillator, IF, FM 
detector, squelch, S-meter output, and data comparator. Unfortunately, ite 
maximum rated operating frequency is only 15@ MHz. Chances are that at least 
some units will work satifactorily at 220 MHz. The addition of a GaAs Fet 
preamp in front of the IC should produce a high performance receiver. The 
MC3356 costs less than $4 in quantities of one, 


Another very promising single chip FM receiver chip is the WNES@5N. Its 
mixer operates up to 1@@@ MHz and its on board LO is goad up te 5@@ MHz' It 
contains an IF amplifier, limiter, FM detector, S-meter output, and a squelch 
switch. An external analog comparator is needed to convert the quadrature 
detector output to a logic level. The NES@5N costs less than #6 for one. 


Another possibility is to convert a NBFM receiver to wide band operation bu 
connecting the IF amplifier and following circuitry from the MC3354 to the 
output from the first mixer. The receiver would then function in both wide band 
and narrow band FM modes simultaneously. 


The transmitter can be of more or less conventional design except that the 
oscillator must be capable of wideband true FM. A suitable oscillator is 
described in Ref 7. Advantage should be taken of this oscillator’s capability 
to operate at the 5th crystal overtone to reduce the number of multiplier stages 
required. fhe oscillator would drive a multiplier chain and power amplifier. 
An oscillator of this type could be substituted for the oscillator ina NBFM 
tranmsitter to convert it to wideband packet operation. 


Unfortunately, wideband radios suitable for 38.4 Kbhaud do not currentiy 
exist so a suitable design must be developed. Fortunately, these new radios can 
be designed for 22@ MHz and above almost as easily as for 144 MHz. It appears 
that a wideband packet radio transceiver is simpler than a NBFM radio and can be 
built Simply and inexpensively. By taking advantage of modern IC’s and circuit 
modules, such a radio could be of simple enough design that it could be built by 
many Amateurs ina few hours. Once it is clear that there is a demand for such 
a radio, manufacturers will begin to build store bought radios and a new era in 
packet radio will begin. 
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PRIORITIZED ACKNOWLEDGEMENT (PRIACK) PROTOCOL 
Eric Gustafson, N7CL 


For the last several years I have been trying to advocate a very minor 

~ change to the AX.25 protocol. This change will allow the protocol to be much 
more compatible with our multiple access half duplex radio channels. I 
requested that the digital committee consider including this change in the 
protocol specification. The committee indicated that the idea might have some 
merit. They suggested that I get some test code written to try it out on the 
air. Since that time, I have worked with Howard Goldstein, N2WX to get some 
beta test code written so that this prioritized acknowledgement (PRIACK) 
channel access system could be evaluated on the air. What follows is a very 
non-rigorous description of the modified protocol. 


While primarily intended to improve channel performance on HF, this 
system will also be useful on any VHF simplex channels where there are hidden 
terminals. 


BETA test code is now available from me for anyone who is genuinely 
interested in participating in the test AND REPORTING THEIR FINDINGS. I have 
no interest in simply distributing ROMs and then never receiving any feedback 
from the user. Two things are needed at this time. First, reports of bugs or 
protocol violations would be most useful for tuning the firmware so that the 
protocol modification itself can be meaningfully evaluated. Second, a valid 
quantitative test of the effect of the protocol modification on a multiple 
access HF channel needs to be done. The code I have is for TNC-2 clones and 
the MFJ-1278. I can be reached at: 


Eric Gustafson, N7CL 
2018 S. Avenida Planeta 
Tucson, AZ 85710 
(602)-747-1410 


I would prefer to deal directly with area test coordinators on 
Compuserve. Those interested in becoming an “area test coordinator" should 
contact me in section 9 of the HAMNET forum on Compuserve. Use a subject 
keyword of "PRIACK". My Compuserve number is 71/750,2133. 


I had originally intended to report the results of testing done at HF 
and VHF in this paper. The initial results of VHF testing done here locally 
on two simplex LANs is very encouraging. Even with small numbers of users on 
the channel the improvement was quite dramatic. Putting the code into the INC 
of a BBS which was on 145.01 (along with users and node inputs) had the effect 
of making the channel functional again for the users. Previously, whenever 
someone accessed the BBS, all other activity on the channel effectively came 
to a halt. So far we have noted no instances of incompatibility with the old 
protocol. 


Unfortunately, HF testing has been slow to get off the ground since both 


of the initial beta test groups have a large contingent of members who are 
using PK-232 TNCs. Until recently this meant that these members couldn’t 
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participate in the test due to not having PRIACK code available for the PK- 
232. This has now been corrected. AEA has recently made some beta test code 
available for the PK-232. I understand that AEA is planning on including 
PRIACK in an upcoming release of generally available code. Hopefully, we can 
now do a meaningful test of the PRIACK system on HF. 


DESCRIPTION 


The idea behind the prioritized acknowledgement (ACK) protocol is quite 
simple. The idea is to give ACKs priority access to the channel so that time 
is not wasted retrying packets that have already been correctly copied but for 
whatever reason, the ACK is not received within the time limit defined by the 
FRACK (T1) timer. 


The present protocol does not handle a simplex LAN with hidden terminals 
as well as it possibly could. This is primarily because, the present protocol 
is more likely to synchronize collisions with acknowledgement packets than 
with any other type of packet. 


To this collision synchronization mechanism the current version of AX.25 
adds a propensity to cause even ACKs which are not from hidden terminals (and 
therefore less susceptible to collision) to be delayed beyond even generous 
FRACK timer settings when the channel gets busy. 


Once the FRACK timer times out, even if the ACK finally makes it through 
before the retry is sent, the original packet is retried anyway. [his 
obviously wastes a lot of time which could be better used clearing the channel 
of some of the legitimate offered load. 


It is this feature of the current AX.25 protocol that accounts for most 
of the abysmally poor performance of the currently popular NETROM and THENET 
nodes when they are used as omnidirectional single channel (or even 
multichannel if there is more than a single other node on each channel ) 
systems. Poor receiver not ready (RNR) condition handling by the current 
protocol is also a contributor here. It should be noted that these node chips 
CAN handle point to point links to a single other node perfectly adequately. 


The prioritized ACK protocol avoids the above problems by giving ACKs 
priority access to the channel. It does this in such a way that even ACKs 
coming from hidden terminals are protected from collision. The current 
protocol gives a limited version of this priority access only to digipeated 
frames. 


ACK prioritization works with slotted channel access in the following 
way: 


1. Response frames (ACKs) are always sent immediately with no time delays 
unrelated to hardware limitations applied. Ultimately, not even data 
carrier detect (DCD) should be checked for sending an ACK. However, in 
the current beta test code, DCD will still hold an ACK off the channel. 
This was necessary to allow compatible operation with non PRIACK 
stations. 
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2. Stations queued up to access the channel but waiting for a channel busy 
condition (DCD true) to clear, will start a slotted access procedure only 
AFTER enough time for a response frame to clear the channel has 
transpired (whether or not the response frame is detectable by the queued 
up station). 


3. Slot time windows are selected to be large enough that the local TNC will 
be able to unambiguously determine whether any other detectable station 
has selected any slot preceding the slot selected by the local INC. This 
is - prevent two TNCs which have selected adjacent slots from colliding 
anyhow. 


As you can see, under this protocol there will never be a condition 
where an ACK is delayed from being sent beyond the FRACK timer limitation. In 
fact, the FRACK timer becomes relatively meaningless in this context. 

However, the FRACK timer is still required to maintain compatibility with 
Stations who are not running PRIACK code. When all station are running the 
PRIACK system, the TNCs know that if they don’t see the ACK immediately when 
expected, they are never going to see it. 


FRACK can be used to force delayed reaccess to the channel when an ACK 
hasn’t been received when expected. However, when all stations on the channel 
are running PRIACK, both FRACK and calculated backoff types of access control 
are completely unnecessary. Here I am assuming that end to end AC digipeating 
will be phased out of the protocol specification now that networking 
development has begun. If layer 2 digipeating must continue to be supported 
(yech!), we should at least convert to point to point ACKs for this purpose. 


On a marginal channel which is lightly loaded, calculated backoffs will 
do exactly the wrong thing by backing off reaccess times on the assumption 
that nonreceipt of ACKs is due to collisions. Under the same circumstances, 
PRIACK will try to get through whenever it isn’t deferred by DCD being true. 
If the channel truly IS busy, PRIACK equitably distributes the channel | 
bandwidth across all the users. This fair distribution is primarily a result 
of using p-persistence slotted channel access control ala Karn and Lloyd [1]. 
It is the combination of prioritized acknowledgements and carefully structured 
slotted access contro] that makes PRIACK so effective. 


Enforcing a channel access delay for all stations on the channel for 
whom the packet that caused the queue was not intended (and who therefore 
aren’t going to ACK it) allows even ACKs from hidden terminals to get back to 
the expecting station. This clears that traffic from the offered load list. 
If the packet was indeed copied and ACKed, further retries of the same 
information will not be necessary. 


The beta test code for this modification to the protocol is compatible 
with stations using the current protocol. A station using the new protocol 
will not degrade the channel for users of the current protocol. So there is 
nothing wrong with firing up the new stuff on a channel where the majority of 
the users aren’t yet using it. Several of us here in the Tucson LAN have been 
running PRIACK exclusively for over nine months now. Other stations on the 
LAN are (so far) completely unaware of this fact. 


HARDWARE LIMITATIONS 


This protocol will not work well if the TNC’s modem DCD characteristics 
are not very good, but neither will any other CSMA based protocol. 


If the TNC uses the 2211 demodulator, the DCD characteristics can be 
readily optimized. A relatively simple modification to the DCD circuit of 
these demodulators is all that is required to make the DCD reliable enough to 
base a CSMA system on. 


If the TNC uses one of the single chip modems intended for land line use 
(like the AMD7910 or TMS3105) or a filter based modem like the PK-232, all is 
not lost but a much more extensive modification is required to rehabilitate 
the DCD circuit. 


The information needed for both of these modifications is in my paper in 
the proceedings of the Seventh ARRL Computer Networking Conference [2]. In 
addition, TAPR has made circuit boards available which eliminate hacking the 
INC circuit board in the case of the 2211 and eliminate the tedious state 
machine wiring task in the case of the other modems. 


In particular, if your DCD circuit has a high false DCD duty cycle when 
listening to noise on an empty channel, the protocol’s ACKWAIT characteristic 
will virtually prevent you from being able to transmit at all. The DCD 
circuit MUST be able to reliably detect the presence of a data carrier but it 
MUST NOT be constantly chattering away on noise. 


TERRESTRIAL APPLICATION ONLY 


The PRIACK system is applicable only to terrestrial communications and 
only in the half duplex radio environment. Long path delays, ALOHA channels, 
and full duplex point to point links all have different requirements and 
should have protocol] specifications tuned to the specific application. Most 
of our layer’ 2 problems have come from one of two sources. One is trying to 
incorporate higher level functions in the layer 2 specification (CHECK etc.). 
The other is from trying to make one layer 2 protocol fit many differing layer 
1 topologies. Unfortunately, what is going on at layer 1 DOES affect the way 
the layer 2 protocol should be structured. 


CONCLUSION 


If we are to optimize our amateur radio protocols, we will have to tune 
the protocol specifications to optimize efficiency based on the layer 1 
limitations specific to the application. I believe that the PRIACK system is 
a necessary protocol tweak for use on terrestrial multiple access half duplex 
radio channels. 


Special thanks to: 
Howard Goldstein, N2WX, who coded these protocol modifications into the TNC-2 


AX.25 code so that we can begin testing with enough stations to make a useful 
statement about performance. 


77 


78 


Martin F. Jue, and Steve Pan of MFJ Inc. for allowing me to release some 12/78 
V2.3 EPROMs with this modified protocol installed. This will be a very big 
help in testing on HF where the need is greatest. 


AEA Inc. for devoting the resources to providing PRIACK code for their PK-232. 
This will be a big help in getting a meaningful HF test accomp] ished. 


Lyle Johnson, WA7GXD, who has contributed many hours kibitzing about the 
various aspects of the protocol and considerable time participating in the 
preliminary on air testing. 

Dan Morrison, KV7B, whose contribution has been similar to Lyle’s. 


Gail Peterson, N7BXX, who has been helping out with the preliminary on air 
testing. 


Mykle Raymond, N7JZT, who has been helping out with the preliminary on air 
testing. 
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Routing, Oh Where is My International Routing 
or 
Where did that order for 10 keys of coke come from? 


William C. Hast, TI3DJT 
Apartado 127-1011 
Y-Griega, 1011 
Costa Rica 


After looking at the state of network routing and they 
way the present networking schemes work I at times wonder if 
we are not going from bad to worse. 


In Central America we have looked at all the routing 
schemes and finally decided on the ROSE X.25 Packet Switch 
due to the fact that it uses recognized protocols for the 
different parts of the network. The entry points of the 
network are easy to determine for traffic in transit across 
non-end point countries. 


Digipeaters, well we all know the pros and cons of that 
so I will not even talk about them! 


TCP/IP looked good but the version now being used does 
not use a universally accepted addressing scheme as far as 
we can determine. It has addresses but in many countries we 
have to live with regulators who only know CCITT and so we 
must have addressing that will comply with some KNOWN 
system. 


We saw the system used by Net/Rom TheNet and made the 
observation that "it works but not good enough" 


Now do not get you feathers up! The problem is not that 
these are bad systems, but they do not take into account the 
problems associated with traffic going across international 
boundaries. 


The question that the GUY/LAW (Big Brother, The 
Authorities, FCC, PTT, or what every the Governing authority 
is) wants to answered about our communications are; 

1. Who sent it? (They all ask that) 
2. Who is it going to? (They ask that one too) 


3. Is there a commercial or CCITT equivalent (Do I have to 
learn anything new?) 
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4. Can we monitor it and determine answers to 1. and 2. 
5. Can you control in transit traffic? 
6. Can you tell what happened and when? 


These and many other questions have been put to many of 
us doing our part for the worldwide amateur digital network 
outside of the USA. Our problems are many times compounded 
by the very fact that we are small countries. We have 
international boundaries everywhere we look and_ the 
regulators care about that fact. Costa Rica is about one 
fifth (19,575 sq mi) the size of Colorado! In Costa Rica we 
cover the country with just three switches, with a forth to 
fill in some small holes. Anything beyond that is in Panama 
on the south, or Nicaragua on the north or San Andres Island 
on the east in the Caribbean Sea. Those are small countries 
and a island much of our communications will be going on 
across their boarders, into countries on down the line. 


As an example say I want to talk to someone in Mexico. 
I will have to link through Three countries to get into 
Mexico. Counting the entry and exit countries I will have a 
total of Five countries involved in the connection. 


Now let us look at those questions that we asked in the 
very beginning. Say I am the LAW in Nicaragua, a good place 
to start since by their very nature they are going to ask 
all they can about what is going on, remember the type of 
government in power!! The local amateur packet group comes 
to me and wants to put up a switch to link Central America, 
the first thing they want to do is monitor this stuff that 
is going in and out of this country, so they ask the 
questions. 


Can we monitor it? We reply yes you can. But if it is 
Net/Rom or TheNet they can not tell where is is coming from 
with out special programs. You can also fool it pretty easy 
such that you can look like you am coming from somewhere 
else in the network. 


ROSE takes care of these problem very simply, it has a 
few more numbers on the address information. We can tell the 
LAWman that those numbers are X.121 (CCITT) and every LAWman 
has X.121 routers for their commercial network. We go on 
beyond that and tell them that the rest is based on the 
local telephone network so then it becomes quite easy to 
figure out where stuff is going to from the monitored 
packets. This X.121 address is PUBLIC information so he can 
tell where both ends of the connection are. Usually the guy 
who asks this question already has X.121 information so that 
makes him even happier and you get a real nice pat on the 
head and 5 "attaboys"!! 


As a example say our LAWman is watching the Nicaraguan 
part of the network and sees packets go by that have 
something like this as the header: 


YN1YA>W1BEL, YN1YN,3100,305689: Text 


This one is going to USA (DNIC 3100 ) and it will be 
sent to area code 305 (S.Fl) and the exchange is 689. He can 
call International Information and find out where the 689 
exchange is in area code 305. 


YN1LYA>W1BEL,7100,43,K4GBB-3* : Text 


This is what the packet would look like at the other 
end. This tells the LAWman in the USA it is coming from 
Nicaragua (DNIC 7110) and the local exchange is 43. 


There are other packets that carry this information 
plus the call of the station on each end, so it is very easy 
to follow all that is going on and if they do not like it, 
turn the thing off or block that circuit. There are also 
commands to display the full addressing information of all 
connections going through a switch. 


I would like to know if you can do that with any of the 
other systems except perhaps the digipeater network (yuck!! 


I know that you can do it with all the networks but you 
need special programs to decode the routing headers. Try to 
tell that to a LAWman who only has a dumb terminal and a 
tnc!! Due to that need you may find you network shut down! 


Thereby bringing us to the usage of CCITT recommended 
systems, if we follow these 5 letters reasonably closely we 
are pretty sure of being able to get permission to set up 
our network, but if we don't we may run into all kinds of 
problems. 


Can any one of the other networks in use today on the 
hambands demonstrate that it follows the Scrrr 
recommendations? Can any of the other networks show with a 
minimum of equipment the entry and exit points of the 
packets going across the network? Is the routing information 
easy to come by? It MUST be public information and it's 
access should be as painless as possible. We can't be 
hampered by Numbers Guru's when we need to expand the 
network. 


You see, as soon as the Central American Network is in 
order we do not think many MINUTES will pass before some 
smart drug COMSTATION tries to send orders through the 
network. On a bbs network that may be pretty easy to follow 
but on a switched network if things are not done right it 
can all be done in the finest of anonymity. 
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Those networks that are already running should think 
about incorporating routing on x.121, if you do it right you 
can reduce your routing tables greatly. It is easy for me to 
route in Costa Rica to other ROSE networks without having to 
know more than the DNIC of the country and in some cases 
just the first one or two digits of the DNIC and no more, 
think about that, you could reduce your routing tables 
greatly by using X.121. I can have a routing table that 
covers the WORLD that only takes 2-3K bytes. 


If we all used the same routing system it would make 
life a lot easier Colombia and Central America have taken 
the step along with Australia and some other countries to 
set up a network based on known standards for routing. 
Something you can get out of your phone book and your 
switched data network. So you guys when you do network 
switches, do them with more than your county, or state or 
even just your country in mind. 


Packet is the WORLD it is GLOBAL and it is time we the 
users and implementers started thinking that way!! If we do 
it will make the network much easier to set up even in the 
most authoritarian of countries. If you don't believe it, 
ask the questions put forward at the beginning of this paper 
about your network and the code used to run your network. If 
it fails on any or all of these questions your network will 
not be usable in many countries. 


Think about it. Meantime we are watching for that first 
"coke" order to come across and when it does we will know 
where it entered the ROSE network at and where it departs 
it. Maybe we can be part of the people who put a stop to 
this horrible business of drugs. Anytime your network can 
give the entry and exit points in a very visible form 
everyone will see that the information is not obscure. Since 
you have this facility at hand maybe they won't try it on 
our network, because they will know that we will know where 
they are on each end! 


Remember we are here among other things to help people 
not help kill them, our network should be the same! 


KA9Q Internet Protocol Package on the Apple Macintosh 


Dewayne Hendricks WA8DZP 
Doug Thom N6O0YU 


INTRODUCTION 


The KA9Q Internet Protocol Package has been out for several years now and 
has made a decided impact on amateur packet radio. It has been implemented on 
several personal computer platforms, with the large majority of hams using it on 
IBM PC’s and its clones. This article describes its implementation on the Apple 
Macintosh family of personal computers. The unique Macintosh user interface and 
its proper utilization by the KA9Q software has proved to be quite a challenge. We 
hope that users of our implementation will be pleased with the results. 


USER INTERFACE DIFFERENCES 


One of the major advantages the Macintosh provides to its users is the 
consistent user interface. This means the user generally has to learn only a few 
commands to become proficient with any program. However this requirement to 
support an ‘ease of use’ interface has caused some implementation difficulties, in 
our port of the KA9Q package to the Macintosh. One of the major issues that we 
had to overcome was the conversion of NET to a modeless program. In the 
Macintosh world all programs are modeless. This means that the user can perform 
any action at any time, regardless of the current state of the program. 


For example, the MS-DOS implementation has a command line orientation. 
The user enters one command after another to cause the program to perform a 
given set of actions. In Macintosh programs the user can perform additional 
functions such as opening desk accessories (i.e. calculator, alarm clock, editor, etc.) 
together with the ability to cut and paste objects between programs at any time. 


In our port to the Macintosh we have attempted to preserve the command line 
interface while allowing the traditional Macintosh functions which require a non- 
modal environment. This has resulted in an implementation which is familiar to 
the typical Macintosh user, but still preserves some of the look and feel of the 
original implementation. 


FILE SYSTEM DIFFERENCES 


One of the initial problems that we had to overcome in our port were the 
differences in the way the volume/directories are setup. In the MS-DOS world, you 
have disk drives, labeled A:, B:, C:, etc. Each volume can further be divided into 
multiple sub-directories, allowing you to logically place your files and documents in 
any location you wish. To specify the location of a document, you would use 
something like this: 
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C:\HAM\PACKET\KA9Q\Net 
On the Macintosh, the notation is quite different. An example best illustrates: 
My Hard Disk:Amateur Radio:Packet files:KA9Q:NET/Mac 


Note that the volume (and folders) may have spaces imbedded in the name, 
and that the names may be up to 15 characters long. Fortunately the only change we 
found necessary was to look for a ':' character instead of the '\' character when 
parsing the filenames and directories. When we need to specify a full path nam~ 
that includes spaces, we just place the entire path in quotes. The implementation of 
these changes to the original package netted one additional feature; the ability to 
specify a different volume and path for each user when they access your station. 
This feature will be explained later in configuring the 'FTP Users' file. 


APPLETALK SUPPORT 


AppleTalk, which is the local area networking protocol built-in to every 
Macintosh, allowed us to provide several additional features. We decided to take 
advantage of this built-in capability by adding a driver to support the AppleTalk 
interface. Here’s and example of how we were able to make use this support. One of 
us has in his QTH, a Macintosh Plus connected to a Yaseu FT-211 via an AEA PK- 
232. However, he does most of his work on a Macintosh IIx located across the room. 
Since AppleTalk is a networking protocol, all he had to do was connect the two 
computers together with a cable, and voila, he can now use his Mac IIx to operate on 
TCP/IP, with no additional radio or TNC required. The AppleTalk support allows 
him to assign another IP address to his Mac IIx, and send/receive files and mail via 
the Mac Plus to other stations. In fact, any number of Macintosh’s can be connected 
(up to the limit of 254) to a single radio/TNC via the AppleTalk network. Appletalk 
also provides connection to LaserWriter printers that are shared on a local network. 
While this seems trivial, the issue is the limitation of two serial ports on the 
Macintosh, one used for the TNC and the other is used for network/ printing. 


MULTIFINDER OPERATION 


MultiFinder, the pseudo-Multitasking environment of the Mac OS, allows us 
to run both Net/Mac and BM/Mac at the same time, each in it’s own area of 
memory. This allows us to send and receive documents/mail while at the same 
time we are answering mail. The only requirement this has, is that we either need 
lots of memory (2.5 Megabytes suggested!), or are very careful in how the system 
files are setup. Although both Net/BM and Net/Mac have been tested on a 
Macintosh 512Ke, there just is not enough memory to run MultiFinder on that 
system, SO we recommend at least a Macintosh Plus for this type of operation. 
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INSTALLATION 
NET/Mac 


Installation is fairly simple. Before getting started, the first thing you must 
do is to get an IP address (or several if you have more than one machine) 
assigned to you. You may wish to contact other TCP/IP users in your area to 
help in obtaining an address. In the meantime you will need to configure the 
system, connect your TNC to the Macintosh, and if you have a hard disk 
attached, copy the necessary files to your hard disk. We suggest you create a 
new folder somewhere on your hard disk, assuming you have one, if not then 
make a backup copy of the distribution diskette to work with. Now copy all the 
files and folders from the distribution diskette into this new folder on your 
working disk. 


oe 


Make note of where you have placed all the files, Volume name, folder, 
etc., as you will need this information to configure several of the support 
documents. 





While there are a lot of commands that may be placed in the Autoexec.Net 
file, only a few are specific to the Macintosh implementation. The ‘attach' 
command specifies to the program which serial port you wish to use to connect 
your TNC, the name you would like to call this port (ax0 in the distribution 
version), the packet size, and baud rates. An example best illustrates a typical 
attach command: 


attach asy 0 A ax25 ax0 2048 256 9600 


This command specifies the Modem port ('A'), packet sizes of 256/2048 
and a baud rate of 9600. 


The following line specifies the use of AppleTalk on the B port and a 
name of at0. 
attach appletalk 77 B arpa at0O 5 600 


The above command specifies the printer port is to be used for Appletalk, 
and that up to 5 packets can be held on the receive queue. The size of the 
maximum transfer unit (MTU) s set at 600 bytes. The MTU size cannot exceed 
600 bytes due to limitations in the AppleTalk protocol. 
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TZone 


One other additional feature we added to Net/Mac project was the 
implementation of the TZone command. This command provides either local 
or GMT time stamping of mail. Below is an example of the command: 


tzone PST 0 


There are two parameters for this command, the first is your time zone, 
PST for Pacific Standard Time, or others as appropriate. The last parameter is 
the number of hours away from GMT you are located. For example here in 
California, we use -8 (subtract 8 hours from GMT to equal local time) when we 
wish to use GMT. If you wish to use local time, just leave this set to 0. 


se of the FT Puser's file as it relates to multiple volume suppor' 


The last file that needs to be edited, is the FTPuser's file. This plain text 
file lists all the user's, their password, and access level to the FTP server portion 
of the program. The only difference in the Macintosh version, is the support of 
foreign volumes. What this means is that we can now have more than one 
disk drive on-line, and point users to one of several volumes. As an example 
you could have a Macintosh running AppleShare™, the fileserver software 
from Apple Computer. Also running from the fileserver could be a land line 
BBS that shares it's files with the TCP/IP station. In this case the FTPUsers file 
would look like this: 


Guest * FS:BBS:MacFiles 1 
WA8DZP Dewayne HD:PUB 7 


The first entry allows anyone who logs into the TCP station with the name 
Guest, using any password, to have read only access to the BBS Files. The 
second entry allows WA8DZP, with the password of Dewayne to have 
read/write access a folder name PUB, on the hard disk (HD). Note that 
NET/Mac, like it's parent program for the MS-DOS world, allows access to all 
folders/files within the specified folder in the FTPuser's file. As a side note 
here... Be careful in how you construct your FTPuser's file. If you have two 
people both named Mike, with different passwords, then only the first Mike 
will have access to your system if you use Mike for the name, and their call 
signs for the password. It is suggested you use one’s callsign as the name entry, 
and their name as the password. 


BM/Mac 
BM/Mac as the name may imply is the mail program for the Macintosh 


version of the KA9Q package. Installation is straight forward, with only the 
bm.re file requiring editing. 





BM/ Mac requires several folders and files to be located in specific places in 
the system. First is the 'spool' folder which contain two additional folders, one 
name 'mqueue', and the other named 'mail'. The mqueue folder contains 
mail files that are queued up to be sent by the SMTP server within NET/ Mac. 
Any mail that is being forwarded through your station will also be kept in the 
mqueue folder The mail folder will contain mail that is received by the station. 


BM.RC fil 


Configuration of the BM/Mac program requires editing the bm.rc file 
which must be located at the same folder level as the program. Below is a 
sample of the entries in the file: 


host N60YU 

user Doug 

fullname Douglas Thom 
reply n6ooyu@nbtoyu 
zone PST 


The first entry specifies the name of the host station. This entry must 
match the same entry in the Autoexec.Net file. The second ‘user’ entry is the 
default name of the user of the system. ‘fullname’ is obvious ‘reply’ is the 
name of the user and his host station name, which is used in the 'reply' field of 
the mail header. And finally zone is the time zone of the station. 


Note: To be compatible with existing PBBS stations, use callsign@callsign in 
the 'reply' field if you plan on forwarding mail to the PBBS network 


Alias fil 


This file is used by BM/Mac to allow the user to setup mail distribution 
lists or alias names for mail recipients. The mailer has been changed to first 
check the alias file for a name before using the information on a 'From:' or 
‘Reply to:' field when generating a return address. This is useful for having 
your own explicit return route to a mail recipient. 


OPERATION 





One of the most useful additions to the Macintosh port has been multiple 
session windows. With this enhancement, every time the user creates a new 
session such as an FIP, a new window is created for that session where all of 
the input and output for the session will appear. The session which was most 
recently created will become the current active session. The user can switch 
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between sessions by either selecting the desired session from the 'Window' 
menu or by clicking upon the session actual window with the mouse. 


The Console session window is the only session window that is active 
when the program is started. Other sessions are created in the normal manner 
from commands issued from the console session. The user can create a 'Log' 
session which shows the contents of the system log from the time the program 
was started. This can be scrolled by the user to see what traffic the program has 
handled since it was started. One 'Trace' session can be started for any active 
interface. The trace window will show the output for the interface as specified 
by the user. Figure 1 below shows an example with three window open. 


é File Edit Windows — 230 & 


Finger - n6oyu 








Name : WAYNE . GREEN |! 
License: W2NSD License Class: A 

‘Mail address: WGE CENTER, PETERBOROUGH, NH 03458-0000 
Station address: RT 202 AND FOREST RD, HANCOCK, NH 

Effective date: Aug. 11, 1987 Expiration date: Aug. if, 1997 
Previous Callsign: Previous Class: 

Birthdate: Sep. 3, 1922 Process date: Aug. 11 


é 


1987 





| AX25: NGOYU->KJ6QA | NR=2 NS=2 pid=Text 

0000 License: WD6GYH License Class: A. 
ax0 recy: 

AX25: KJ6QA->N6GOYU RRCP) NR=1 

ax0 sent: 

AX25: N60VU->KJ6QA RRACF) NR=2 


net> finger Sw2nsd@n6oyu 

}net> 

You're being fingered by 44.4.1.209:1008! (Sun Jul 16 14:29:09 1989) 
net> 


Figure 1 


Finger session windows are handled in a special manner. They are 
allowed to stay open after the session has closed. This allows the user to have 
access to the information displayed in the window until it is no longer 
required. In addition, the 'Finger', ‘Log’ and ‘Trace’ session windows are 
treated as write-only. Since no input is allowed in these sessions, none is 
allowed in the window. 


All session windows may be re-sized and placed on the screen in any way 
the user desires. This allows the activity on several sessions to be observed at 
the same time. This has proven to be a very useful feature during normal 
program operation. 


MACINTOSH SPECIFIC ENHANCEMENTS 


Hel a 


Another useful addition has been the on-line Help Facility to both 
NET/Mac and BM/Mac. The facility is activated when the user selects it from 
the 'Apple' menu and provides documentation on all of the commands 
available in each program. Examples are also provided for all of the 
commands, so that the user has some idea has to how each one should be used. 
Normal program operation continues while the Help Facility is active and 
when the user is done they can remove it by clicking on its window’s close box. 
Figure 2 shows the initial Help display. 


_@ File Edit Windows = ——“(‘ié UR SI 





applestat Command 
arp Command 
attach Command 
ax25 Command ne 
I] {ce Commend =] KAQQ Internet Software 
| | close Command <=) Apple Macintosh Version 


ne haere _| © Copyright 1988, Phil Karn | 


disconnect Command ae petcase | 


console — 


You're being fingered by 44.2.0.54: 1001! (Sun Jul 16 12:32:43 1989) 

net> 

You're being fingered by 44.4.0.22:1005! (Sun Jul 16 13:37:05 1989) 

net> finger &n2nsd@n6oyu 

| net> 

| You're being fingered by 44.4.1.209: 1007! (Sun Jul 16 14:28:50 1989) 
net> finger S%w2nsd@n6oyu 

net> 

sie being fingered by 44.4.1.209: 1008! (Sun Jul 16 14:29:09 1989) 
net> 
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In order to make it easier to transfer files between Macintosh systems 
running NET/Mac, the MacBinary II file transfer protocol has been added to the 
program. This protocol sends along with the normal data in a file, all of the 
Macintosh specific file information (i.e. program specific icons for the desktop). 
This is necessary as the Macintosh file system is quite different than that of MS- 
DOS systems and require additional information that is not transferred when 
an ‘image’ mode FTP transfer is done. A new sub-command “Macb” was added 
to the FTP client/server to provide this support. If a Macintosh user attempts 
to issue this command to an FTP server which is not on a Macintosh, then it is 
ignored. 


AppleTalk Support 


Support has been provided for communication to other Macintoshes 
running NET/Mac over an AppleTalk local area network by the addition of a 
Link Access Protocol (LAP) driver. With this driver, Macintoshes in the same 
zone can transfer ARP and IP packets to each other. The driver at this time 
does not allow communication across zones or internet operation. 


FUTURE DIRECTIONS 
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In the near future, the next generation of the KA9Q Internet package, the 
Network Operating System (NOS) will replace the current version. At that 
time we expect to port all of our modifications and enhancements to that 
environment. As the architecture of the Macintosh is quite different from that 
of MS-DOS based systems, we expect that this will be a major undertaking 
which will require the direct replacement of many parts of NOS with 
Macintosh specific code. The Macintosh already has a multi-tasking 
environment called MultiFinder which provides many of the services 
implemented in the NOS kernel. We expect to make use of those services in 
our port of NOS to the Macintosh. 


-Appli 


Apple recently announced a inter-application communication protocol 
(IAC) which will be available sometime in 1990. We expect to implement this 
protocol in the NOS version to allow Macintosh applications to inter-operate 
over a TCP/IP network. One application already planned for this interface is a 
callsign lookup server. We expect that this support will allow to have the 
callsign application access the callsign data in an SQL database running on a 
different host on the network. 


: . * ? bail ? a 
nteroperation with other Macintosh | 7/1P Implementations 


There are several other TCP/IP implementations available on the 
Macintosh. The most popular is from the National Center for Supercomputer 
Applications (NCSA) and is available in the public domain. Apple has recently 
released their own version of TCP/IP, MacTCP which supports both AppleTalk 
and EtherTalk networks. We plan to provide support in NET/Mac to 
interoperate with both programs. This will greatly extend the utility of the 
program as a means of interconnecting different networking systems. 





With the Inter-Application interface support mentioned above, in order to 
provide a platform for the implementation of general applications we will 
need a generic terminal interface for the applications to talk to. We intend to 
implement a VT-100 style terminal session as an enhancement to the existing 
Telnet client/server. We had entertained the notion of providing only a 
Macintosh screen interface, but if we did this we would not be able to inter- 
operate with applications on other non-Macintosh platforms. The VT-100 
interface is commonly used in the industry and supports a superset of the 
ANSI standard escape sequences. We feel that this support will provide a good 
foundation for general application design. 


CONCLUSION 


The port of the KA9Q Internet package to the Macintosh has proven to be a 
very rewarding experience. The package on the Macintosh has quite a different look 
and feel then on some of the other platforms on which it is available. We hope to 
continue our efforts in improving the user interface of the package in order to 
provide the general packet community with an very easy to use, 'appliance-like’ 
version of TCP/IP. We hope that our efforts will make TCP/IP available to more 
hams interested in exploring this new dimension in packet radio. 
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PROTOCOL LEVEL 8 
or 
WHAT ABOUT THE USER? 


by Lyle V. Johnson, WA7GXD 
9991 East Morrill Way 
Tucson Arizona 85749 


BACKGROUND 


In 1981, Amateur packet radio was highly experimental. As late as 
1984 there were serious questions of packet’s viability as a useful 
mode in Amateur radio. 


The early days of the packet revolution were filled with digital zea- 
lots proclaiming the virtues of the new mode. Their fervor spread, 
and Amateurs by the thousands climbed aboard the bandwagon. In 1989, 
with well over 100,000 TNCs in daily use in Amateur stations around 
the world, there is no doubt that packet is here to stay. 


The question now? 


Is packet to be useful to Communicators, or will it remain in the do- 
main of the Techies? 


YESTERYEAR’S PACKET PIONEER 


In 1983, the TAPR Beta test demonstrated that groups of Amateurs, 
given operable equipment, could use packet on VHF to send data within 
a local group. It also demonstrated that a local group was necessary 
to assure sufficient technical know-how in getting packet stations on 
the air. 


PACLEN, MAXFRAME, TXDELAY and DWAIT became bywords. Arguments raged 
regarding the interpretation of <CR> and <AUTOLF>. Manuals included 
lengthy appendices describing the intricacies of Level Two protocol. 
Anyone who didn’t know the difference between hardware and software 
HDLC simply wasn’t educated, and everyone who thought they did know 
would immediately jump on the channel and discuss the issue! 


Hours were spent at club meetings and hamfests across the land descri- 
bing the wonders of bit-stuffing, the magic of transparency and the 
evils of excessive packet overhead. 


WINDS OF CHANGE 


When TAPR marketed TNC kits (1983 through 1985), the first units were 
grabbed up and built by the techies. There were questions to answer 
and technical support to provide, but by and large the folks who 
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bought and built the early TNCs were able and willing to wade through 
hundreds of pages of documentation to configure and operate their 
packet stations. 


Towards the end of the kitting experience, however, a definite trend 
emerged. More and more people were buying and building the kits, but 
not understanding the complexities of the TNC hardware and firmware. 
Kits were sent in for repair that had been improperly soldered and 
with sometimes gross errors in assembly. Questions were being asked 
that reflected inexperience in computing and data communications 
concepts. Many questions demonstrated a lack of understanding of 
basic commands and timing relationships of the AX.25 protocol. 


TODAY’S PACKETEER 


Many Amateurs today are not particularly technically inclined. This 
is neither good nor bad; it simply is. 


It is useless to bemoan the bygone days of home-brew equipment. To- 
day’s bands are too crowded for efficient work with a spark gap trans- 
mitter and coherer detector. 


Many people try HF packet and give up. They blame the demodulator (or 
the zealot who told them it was possible). 


Many digipeaters and single-port network nodes are on hilltops with 
omnidirectional antennas. Folks who try to get through using these 
systems claim, "Packet doesn’t work!" They blame the mode and ignore 
the practical impact of the implementation of the mode. 


We live in a generation which requires illustrations rather than 
words; simplified explanations rather than rigorous understanding. 


The purpose here is not to belittle or condemn. The point is simply 
that many people now getting on packet are not technical people. 
Packet is not the end, but simply a means to other ends. These folks 
simply wish to communicate. 


YESTERYEAR’S PACKET EQUIPMENT 


Early automobiles required mechanical aptitude to operate. You had to 
set the spark, hand-crank the engine, patch the tires, adjust the 
throttle, squeeze the horn, double-clutch when shifting, wear goggles 
and tolerate the weather. 


For this effort, you were rewarded with the ability to exceed 15 miles 
per hour and go uphill in reverse gear only. 


Early packet equipment included numerous commands to configure the TNC 


to every conceivable type of terminal or computer. The user had to 
understand the meaning of NULLS, ASYNC PORTS and so on. 
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Manufacturers entering the packet fray struggled to outdo each other 
in advertised number of commands. Simpler equipment included non- 
mnemonic commands and required the user to not type when the radio 
channel was busy. 


Yes, early packet gear was troublesome to interface and difficult to 
understand. 


TODAY’S TNCS AND MULTI-MODE CONTROLLERS 


Today’s automobiles include climate control, compact disc audio sy:- 
tems, power sun roofs, automatic transmissions with overdrive and 
speech synthesized messages to tell you to add water to your 
windshield washer’s reservoir. 


Today’s TNCs include numerous commands to configure the TNC to every 
conceivable type of terminal or computer. The user has to understand 
the meaning of NULLS, ASYNC PORTS and so on. 


Manufacturers struggle to outdo each other in advertised number of 
commands. 


Multi-mode controllers are even worse, often with literally hundreds 
of commands. 


Yes, early packet gear was troublesome to interface and difficult to 
understand. Today’s packet gear is more troublesome and difficult. 


Progress nowadays means providing on-screen menus to crowd the myriad 
commands into little boxes that you can point to and alter. Organiza- 
tion may be better; a user’s technical understanding requirements are 
at least as bad if not worse. 


CAN WE IMPROVE THE SITUATION? 
Allow me one last comparison. 


Many folks today go out and purchase an MS-DOS computer. With an in- 
stalled base of over 10 million units, you’d think the industry would 
be able to cater to the casual user. 


Not so. 


If you are a techie, you have undoubtedly been asked by people to help 
them set up their computer or format their hard disk so they could use 
their database or spreadsheet or word processor. In other words, 
these folks are interested in using the computer. They are not 
interested in the theory and operation of computing. The computer is 
a tool; the application program is the reason for obtaining the 
computer, 
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In the same light, it is my contention that many people getting on 
packet today couldn’t care less about bit-stuffing and HDLC. They 
simply want to send data reliably from point A to point B. The mech- 
anics of how the data gets there is of no interest. The mode is a 
means, not an end. 


For these people, it is unreasonable to expect them to learn of the 
intricacies of Level Two (or higher) protocol. They drive cars with 
automatic transmissions. They don’t want to have to use a clutch to 
send data. 


SUGGESTIONS FOR THE 90S 


In the 1990s, Amateur packet gear needs to be built for communicators. 
Command sets ought to be simplified, and the microprocessor should 
make many of the decisions now required by the user. 


For example, the user’s serial port, which connects to his computer or 
terminal, needs only the following options: 


Data rate (baud), word length and parity. 


Data rate can be automatically detected and retained. Word length is 
one of two choices. Parity is tied to word length, with even parity 
for 7 bits and no parity for 8 bits. The user now has to make only 
one decision (word length/parity). 


Historically, TNCs were used with mechanical ASCII terminals running 
at 110 baud. (If someone really wants to run an antique like this, 
they can just as easily run an antique TNC that allows NULLS, odd 
parity and so forth! ) 


Almost everyone on packet nowadays uses a personal computer of some 
sort. The software in the personal computer allows setting up data 
rates, word length, parity, etc. So, rather than force the user to 
make several selections at both ends of the serial line, make the TNC 
a limited subset, then clearly document the subset. 


Most telecomm programs default to 7 bits, even parity, 1200 baud. The 
TNC should match these defaults. Use of 8 bits and no parity may be 
easily selected for sending binary data. By careful selection of the 
key the user strikes to establish the data rate (carriage return, for 
example), parity can also be auto-detected. The user then has to make 
no selections regarding the serial port. 


Other areas of simplification could involve the user telling the TNC 
how he is using the TNC, rather than specify everything to the TNC in 
exhaustive detail. 


For example, the user could tell the TNC he is operating on HF, or 


VHF/FM or Satellite. The TNC would then set the TXDelay, FULLDUP, 
DWAIT, DIGIPEAT, MAXFRAME, PACLEN and other parameters to reasonable 


95 


defaults. If VHF/FM, the user could further specify whether a 
repeater was to be used, allowing setting of AXDelay and AXHang. 


A first step in this direction has been taken by AEA in their PK-88 
and PK-232 systems. If the user invokes the KISS command (SLIP 
protocol), system defaults are altered to automatically adjust to this 
environment. 


A number of timing and other "link" parameters can be fully automated 
rather than simply auto-defaulted. For example, the MSYS packet 
bulletin board system software watches retries and alters PACLEN 
dynamically. See my paper on Thoughts on an Adaptive Link Lev: 1 
Protocol elsewhere in these proceedings for some ideas in this regard. 


CONCLUSION 


The purpose of this paper is to get people thinking about command 
structure simplification for packet radio controllers. Packet has 
grown from a newborn to adolescence. Whether it becomes a useful men- 
ber of our Amateur communications society, or a merely ne’er-do-well 
of great potential, depends on how well its implementations match the 
user community that will apply it to solving communications problems. 


Thoughts on an Adaptive Link Level Protocol 


by Lyle V. Johnson, WA7GXD 
9991 East Morrill Way 
Tucson Arizona 85749 


ABSTRACT 


A look at HF channel conditions and historic Amateur radio practice 
reveals weaknesses in current packet radio link level protocol 
implementations. In line with the author’s views of how protocols 
should work (see Level 8 Protocols elsewhere in these Proceedings), 
some features of ALink90, an experimental link-level protocol, are 
described. 


CHANNEL CONDITIONS FOR AMATEUR PACKET ACTIVITY 


Amateur rf paths for data have a number of departures from the ideal. 
The characteristics noted below are aggravated on HF, but they are 
generally true on VHF channels as well. 


Low Speed / Narrow Bandwidth. 


Most Amateur packet activity occurs at 300 bps on HF channels, 1200 
bps on VHF/UHF channels. 


Shared Channel 


The Amateur service denies the luxury of individual users "owning" 
specific frequencies. Except for coordinated repeaters, everyone has 
an equal right to available frequencies. As a result, frequencies 
must be shared. Packet is one of the few digital modes which allows 
such sharing. 


Hidden Transmitters 

Along with shared channels, most Amateur packet activity occurs on 
channels with hidden transmitters. This means that not all stations 
can hear all other stations. This may be due to range, shadowing, 
differing power levels or other reasons. 


Noise 


Amateur frequencies are typically noisy. Weak signals, combined with 
multipath distortion, are common on HF as well as VHF/UHF. 


Half—Duplex 
Amateur gear is almost exclusively half-duplex. Amateur operations 


are almost exclusively half-duplex. This simply means that you cannot 
normally receive at the same time you are transmitting. 
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HISTORIC AMATEUR OPERATING PATTERNS 


Radio is often used for roundtable discussions. Voice and CW nets 
with designated control stations and a variable number of check-ins is 
another common Amateur use. Of course, Amateurs also engage in one- 
on-one conversations by radio. Many times, an Amateur station does 
not previously know the station contacted (calling CQ). 


Telephones are used for one-on-one conversations. The calling party 
deliberately dials the called party. The called party is usually 
known in advance of the call to the calling party. 


As a result of these differences, telephone-based protocols may not be 
optimum for radio usage. 


AX.25 LINK LEVEL PROTOCOL LIMITATIONS 


The AX.25 Level Two protocols (versions 1, 2.0 and 2.1) provide 
reliable information transfer between two stations when signal levels 
are good and there are no hidden terminals. 


A number of the deficiencies in versions 1 and 2.0 have been addressed 
in version 2.1. 


Still, point-to-multi-point communications are not provided for. 
Retries are handled by pinging the other station before resending the 
data. Multiple frames are used for lengthy transmissions, adding 
overhead. There is no automatic methodology specified for tailoring 
the various protocol timers and variables to the RF path in use, 
placing a large technical burden on often naive users. And the 
protocol specifications are lengthy and complex. 


Recognizing that AX.25 Level Two is not a panacea for all situations, 
the ARRL and others are actively working on developing a suite of 
protocols to handle various media (HF, satellites, etc.). 


ALink90 PROTOCOL FEATURES 


ALink90 seeks to resolve many of the deficiencies of current Amateur 
HF protocols. ALink90 provides the following features: 


Protocol Timers Gated with DCD 


The only timers used are for retry. If the channel is occupied, you 
shouldn’t transmit. Your re-transmit timer shouldn’t run, either! 
This requires the TNC modem to provide a data carrier detect (DCD) 
signal only when it senses other stations’ signals. 


Unconnected Mode Operation 


ALink$0 supports acknowledgments, but not connections. Connected mode 
operation is possible, however, when running higher level protocols. 


No Digipeaters 


A link protocol should only operate between stations in the same RF 
domain. Range extension should be handled as a Level 3 function. 
ALink90 is concerned with the task of getting chunks of information 
from one station to another (or others) ina single hop. 


ARQ Operation 


ALink90 doesn’t incorporate forward error correction techniques. 
Instead, it relies on the receiving station(s) to send explicit 
acknowledgment (ACK) upon receipt of uncorrupted data. 


HDLC Format 


ALink90 would be useless if it couldn’t run on existing hardware. 
Thus, it uses standard HDLC techniques for operation. 


Prioritized Ack 


If a data transmission occurs, the destination station(s) will send an 
ACK immediately. The sending station will then have the best 
opportunity to determine if the frame just sent was received. 


Stop-and-Wait 


ALink90 allows only a single frame in flight between stations. 
Another frame will not be sent until the current one is ACKed. This 
simplifies the protocol, minimizing memory and processor requirements. 


a a 


The station sending data will respond to a received ACK by either 
sending more data (if more data is presently available) or an ACK-ACK. 


Data is allowed to flow only one way at a time in ALink90. Thus, the 
ACK-ACK is a way of automatically turning the link around in a similar 
fashion to manually sending +? in AMTOR. 


P-Persistence for Channel Access 


Since the channel must support multiple QSOs, p-persistence is used to 
socially balance the users. If a station has data to send and detects 
the channel is clear, the station won’t necessarily send the data 
immediately. This allows other stations that may be waiting to have a 
chance at accessing the channel to send their data. 


Persistence Value Dynamically Adjusted 
The number of users on a channel varies. For example, at 7 P.M. ona 
Sunday night, the local VHF channel may be very busy, but become very 


quiet by 3 A.M. ALink90 dynamically adjusts the probability of 
accessing the channel based on measured channel occupancy. 
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Frame Length Dynamically Adjusted 





Although ALink90 allows only one frame in flight between stations, it 
tailors the maximum allowed length of the frame based on the path 
between the stations (not on channel occupancy). A fast-attack, slow- 
decay algorithm is used to adjust the maximum allowed frame size. In 
order to support reducing the length of a frame already sent but not 
acknowledged, automatic fragmentation is included in the down-sizing 
of the frame length. Fragmentation is a part of the retry process, so 
no data need be lost while the protocol adjusts to path conditions. 


Multi-Way Connects 


ALink90 allows as many as nine (9) stations to participate in a multi- 
way QSO. If the paths are good, data need only be sent once for 
guaranteed delivery to all other stations. If conditions deteriorate, 
or if one or more links are marginal, data may have to be re-sent. A 
slotted acknowledgment scheme minimizes the channel bandwidth needed 
to support multi-way QSOs. 


Existing schemes for packet roundtables either assume all stations can 
copy all others at all times and go "UNPROTO" mode (utopian 
conditions), or the data is sent to each individual station and 
acknowledged (extremely wasteful of channel bandwidth). 


Callsign is Address 


Callsigns of up to 15 characters are allowed. There are no 
restrictions on the characters that may be used in the callsign field. 


Multiple "Connects" Allowed 

There is no restriction on implementations to allow a given station to 
participate in more than one QSO at a time. This is a function of a 
higher level than the link. However, ALink90 still requires that a 
station may only send data to one station (or group in the case of a 


multi-way QSO) during any data transmission sequence. This is for 
social balance -- no station should be allowed to "hog" a channel. 


STRUCTURE OF A FRAME 

The byte order of the various fields sent in a frame is: 

SYNC FLAG HASH LID SRC DEST CNTL FID FRAG NID DATA FCS FLAG 

The meaning of each field will now be explained. 

SYNC 

Preframe syne consists of a stream of zeroes during this station’s 
transmit keyup delay time. These synchronizing zeroes will speed 


lockup of the receiving station(s) demodulator clock recovery 
circuits. 
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FLAG 


The flag is the standard HDLC value of 7E hex, with no bit stuffing. 
This flag marks the beginning of a frame. 

HASH 

For point-to-point links, this is an 8-bit value corresponding to the 
encoded callsign of the destination station. For multi-point QSOs, 
the value is set to FF hex to exploit the use of hardware HDLC 
controllers with address recognition capabilities. 


The algorithm used is a simple 8-bit summation of the callsign field, 
excluding length byte: 


[SUM(n) = sum(n-1) + byte(n)] 
LID 


The Link ID is used to identify the link level protocol in use. A 
value of 02H is initially being used to identify ALink90. 


SRC 


This is the callsign of the sending station. It is prefixed with an 
eight-bit character count which serves as a pointer to the next 
address in the queue. While 15 characters are allowed in this field, 
it may be as short as a single character (plus character-count). 


Character encoding may be arbitrary. It is recommended that ASCII 
encoding be used, and that upper case characters be used, along with 
numerals and the "/" character. 


There is no bit shifting. Further, the callsign field is simply an 
address list. There are no command or response bits, no digipeater 
bits and no other control bits buried in it. 


DEST 


This is a list of callsigns of the destination station(s). It may be 
a minimum of one (1) callsign field and a maximum of eight (8) 
callsign fields. The callsigns are encoded as in SRC, above. 


CNTL 


The control byte is used to control the information flow on the data 
link. It presently allows two types of data frames and four types of 
supervisory frames. 


Data frames are used to frames convey information to the other 
station(s). These frames may or may not require an acknowledgment. 


Supervisory frames indicate data frame acknowledgments, acknow- 
ledgments to data frame acknowledgments, error recovery and TNC busy. 
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A simplified control field structure allows simple bit masking or 
shifting instructions to be used in software to determine frame types 
and actions required. 


FID 


The Frame ID is an eight-bit value which changes when a frame is being 
sent that is different than the last one. It remains constant 
throughout a frame fragmentation/de-fragmentation procedure. 


There is no requirement that FIDs be consecutive, only that an FID be 
different than the last one originated from this station in a 
particular QSO. 


FRAG 


The fragmentation field indicates the size of the frame length allowed 
and where in the possible frame space of 4096 bytes the present 
fragment fits. This field is a single byte, and is always sent. 


NID 


The Network ID byte is used to indicate the next higher level of 
protocol being used, if any. If none is used, a value to be 
negotiated with the ARRL Digital Committee will be sent. Initial 
experiments use a value of FO hex to indicate no higher layer. 


DATA 


This is a field of an arbitrary number of bytes. The only limitation 
is that it must not exceed the currently allowed maximum frame length. 


FCS 

This is a 16-bit CRC based on ISO 3309. 

FLAG 

This flag is identical to the one which marks the beginning of a 
frame. This one marks the end of the frame. The station transmitter 


should shut down immediately after sending this flag. Trailing bits 
after this flag will be ignored by the receiving station(s). 


Since there is only one frame allowed per transmission, a single flag 
byte cannot mark the end of one frame the the beginning of a following 
frame. 


CHANNEL ADJUSTMENT 
ALink90 incorporates a number of special features to dynamically 
"tune" its operation to channel conditions. It carefully differenti- 


ates between channel occupancy and channel quality. These features, 
and the algorithms to implement them, are described below. 
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DYNAMIC FRAME SIZING 
Overview 


A QSO is initiated with a frame length allowed of 128 bytes. Fragmen- 
tation allows reducing this size without losing data being transferred 
between stations. 


The maximum frame length allowed is 32 bytes at the low end, 4096 
bytes at the high end. 


If the channel can support longer frames, it is allowed to do so. If 
the path becomes noisy, frame length collapses rapidly and 
fragmentation occurs quickly for this frame. 


Algorithm 


The permitted frame length increases and collapses according to the 
following rules: 


NOTE: Nilo is the retry count for the station originating (sending) 
the current frame. 


1) Start with frame length = 128 bytes. This is a reasonable frame 
length to start with under typical 1989 operating conditions. 


2) If data flows to other station(s) with no more than two frames 
retried and no frame retried more than once during the last eight 
frames, and if at least two of the last eight frames were longer 
than 50% of the allowed frame length, double the allowed frame 
length. 


This means that if the channel quality is good and there is 
sufficient data in the queue to warrant attempting it, cautiously 
increase the frame length. 


3) Repeat step 2 until allowed frame length = 4096, 


4) If retry for a given frame is two (Nlo = 2), divide frame length 
by four (but the value must not be less than 32), fragment this 
frame and try again. Do not clear Nilo. 


If retries are beginning to build up, aggressively back off the 
maximum allowed frame length. 


5) If Nlo = 4, divide allowed frame length by four (but the value 
must not be less than 32), refragment this frame and try again. 
Do not clear Nlo. 


6 ) If Nlo = 6, set allowed frame length to 32, refragment this frame 
and try again. Do not clear Nlo. 
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FRAGMENTATION 
Overview 


If the frame being sent is too long for the path to support, it must 
be fragmented into smaller frames at the sending end, and properly 
sequenced at the receiving end. In some cases, the frame must be re- 
constructed into a single, larger frame at the receiving end for 
proper operation of a higher-level protocol. 


ALink90 provides both a frame ID and a fragmentation byte to allow 
this to happen automatically and transparently. 


Algorithm and Control Field 


The fragmentation byte is encoded to show the level of fragmentation 
(maximum frame length versus 4096 bytes allowed by the protocol) and 
the location within in the 4096 byte possible frame that the fragment 
fills. This encoding technique allows dynamic frame sizing to occur 
during the transfer of the fragmented frame. 


The fragmentation byte is encoded as follows: 


Bit Frame Length 
S842 321 0 

Onnn nannnin 32 

10nn nnonn 64 

liivovn amnmnn 128 

1122320 2 mH 256 

‘£3421 602 wR 512 

jE PLO s 1024 

bZSAT £LOR 2048 

Li£kLd &LiI © 4096 

'rizti gigs Frame not fragmented 


The "walking 0" is used as demarcation of the size information (high 
order ones) and the pointer to the start of the current frame’s 
information field within the 4096 byte possible frame (values of n). 


The receiving station places the data field received in the 4096 byte 
frame being reconstructed at the location specified by n. This is 
done even if this field has already been received at a different size 
level for this frame ID. This method allows dynamic frame sizing to 
occur even while sending a fragmented frame. 


DYNAMIC PROTOCOL TIMERS 
Overview 
The only protocol timer used in ALink90 is Tl, the retry timer. There 


are two Tis - Tlo for the originator (sender) of the current data 
stream and Tid for the destination (recipient) of the data stream. 
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The timers are gated with DCD from the moden. Therefore, the TNC 
won’t be counting time when other stations are using the channel. 
This automatically "backs-off" the rate of introduction of data to the 
channel by this station when the channel load increases. This is not 
enough, however, to maximize the efficiency of the channel. 


ALink90 assumes there are other stations using the channel. Further, 
it assumes that any particular station will not be able to hear all 
the other users of the channel, but that one (or more) of the stations 
in the current QSO may hear some of these "hidden transmitters." 


The protocol makes a further assumption that the hidden stations, with 
whom the rf domain of the present QSO may overlap, find their paths to 
be about as good as this station finds its path(s). 


Algorithm 


Tlo allows at least two other stations to be hidden and send data 
frames with frame lengths as long as this station allows. Therefore, 


Tlo = bit_time * 8 * (frame_length_allowed + overhead) * 2 


A maximum length overhead is 9 call signs of up to 15 characters plus 
9 byte counts, a two-byte FCS, two flag bytes, an LID byte, an NID 
byte, an FID byte, a fragmentation byte, a control byte and a hashing 
byte, for a total of 54 bytes. A typical overhead byte count for a 
point-to-point QSO between two stations with 6 byte callsigns is 24 
bytes. Current AX.25 usage is 20 bytes under the same circumstances. 


Hidden transmitters may disrupt an incoming ACK. Since ACKs will 
usually take much less time to send than data, Tld is set to a value 
of Tlo/4. This means that, on average, four (4) ACKs will have to be 
missed by the originating station before it re-sends the data (and 
increments its retry counter). 


Since the fragmentation byte of the received frame tells the receiving 
station the frame_length_allowed by the sender, it is a simple matter 
for the receiver to set its Tid to the appropriate value. 


Finally, since a prioritized ACK scheme is implemented, the sending 
station will usually not have to wait to receive am ACK. Thus, when 
conditions are good, data will flow rapidly. 


DYNAMIC P-PERSISTENCE SELECTION 
Overview 


Channel access probability should be based solely on channel occupancy 
by other users. It should not be based on channel propagation 
efficiency (noise) or other path-related concerns. 


Current approaches to addressing congested channels cause the retry 
timer (T1) to rapidly increase in value, reducing offered load to the 
channel, if an ACK isn’t received when expected. This has the 
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undesirable effect of reducing load to a channel that is not occupied, 
but merely noisy. Still, it is the correct approach if round-trip 
time is the only criterion upon which offered load is based. 


ALink90 gates Tl with DCD, so Tl is effectively backed off as a result 
of channel occupancy, not channel quality. Prioritized ACK has the 
effect of usually telling the originating station immediately if the 
frame got through. 


Dynamic updating of the persistence parameter, p, based on channel 
loading can help reduce retries based on channel congestion. 


If there are no other users on the channel, the persistence value 
selected should approach 0.9. A value of 1.0 would either prohibit 
other users from accessing the channel, or ensure collisions and 
retries if they attempt to. If there are many other users on the 
channel, the persistence value selected should approach 0.1. z= it 
needs to be less than this, there are too many QSOs on this channel! 


Algorithm 


The probability of accessing the channel to send data is expressed as 
p.- If p = 1, the TNC will send if the channel is clear. If p = O, 
the TNC will never send. ALink90 allows p to range from 0.125 to 
0.875, based on channel occupancy. 


A 7-minute moving average, updated every 25.5 seconds, is maintained 
of detected channel use. This is done by gating a 100 mSec sampling 
counter with DCD. P is then (one minus the measured channel activi- 
ty), limited at the busy case to 0.125 and limited to 0.875 if the 
channel appears unused. 


MULTI-WAY STREAMS 

Overview 

ALink90 allows multi-point conferencing, or roundtable discussion, for 
up to nine stations without individually sending the data to each 
station. This multi-way system is especially suitable for group QSOs, 
small nets (DX alerts and so forth) and for inter-BBS forwarding of 
bulletins and other targeted information dissemination. 


Implementation and Algorithm 





The address field can contain up to nine stations. The first field is 
the sending station. The second through ninth are the destination 
stations. 


A slotted, prioritized ACK scheme is employed, with additional ACKs 
sent as needed based on expiry of each station’s Tld timer. 


The prioritized ACKs are sent by the destination stations in their 
order of appearance in the address field. The algorithm used is: 
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1 Delay (Position _in_address field - 1) * (TXD + ACKTIME) 
2) Send ACK, start Tid. 


Where: TXD is xmtr keyup time, defaulted to 50 mSec. 
ACKTIME is 35 * 8 * bit_time. 


Subsequent ACKS, based on expiry of Tid, follow normal channel access 
procedures. 


Other stations on the channel, upon decoding any information frame, 
will wait this amount of time before attempting to access the channel. 
Thus, even if a station can’t hear all the ACKs, it will refrain from 
colliding with any of the ACKs (assuming it hears the data frame). 
Further, if a station hears any decodable frame, it will wait at least 
one ACK time before attempting channel access. 


CONCLUSION 


A straightforward, adaptive link-level protocol tailored for the 
Amateur packet radio environment has been outlined. Although not 
compatible with current versions of AX.25, a number of the ideas 
presented here could be incorporated in other link level protocols, 
perhaps even in AX.25 version 3.0. 


ALink90 is not intended to supplant AX.25. Rather, it is an 
experimental protocol for further investigation into automating link- 
level and media-access decisions. The goal is optimizing the 
efficiency of limited bandwidth, multi-user packet radio channels. 


REFERENCES 


Beattie, Gordon Jr., Fox, Terry and Moulton, Thomas. "Amateur Framing 
Protocol" Proceedings of the 7th ARRL Computer Networking Conference. 
ARRL:Newington, CT. 1988. 


Fox, Terry. AX.25 Level Two Version 2.0 Protocol. ARRL: Newington, 
CT. 1984. 


Gustafson, Eric. Letter to the ARRL Digital COmmittee proposing 
Prioritized Acknowledgments. December, 1987. 


Johnson, Lyle. "Some Thoughts on AX.25 Level Two" Proceedings of the 
3rd ARRL Computer Networking Conference. ARRL:Newington, CT. 1984. 


Karn, Phil and Lloyd, Brian. "Link-Level Protocols Revisited" 


Proceedings of the 5th ARRL Computer Networking Conference. 
ARRL: Newington, CT. 1986. 


Scace, Eric. "Overview of ARRL Digital Committee Proposals for 
Enhancing the AX.25 Protocols into Revision 2.1" Proceedings of the 
7th ARRL Computer Networking Conference. ARRL:Newington, CT. 1988. 


Tanenbaum, Andrew S. Computer Networks (Second Edition). Prentice- 
Hall:Englewood Cliffs, NJ. 1988. 


107 


108 


Tucson Amateur Packet Radio 
packetRADIO Project 


TAPR packetRADIO Development Team 


Written by : Greg Jones - WD5IVD 
Introduction by : Andy Freeborn - NOCCZ 


Abstract 

This paper will discuss the Tucson 
Amateur Packet Radio  packetRADIO 
project. Technical and design 
considerations will be explained and 
discussed. Beta-testing of the radio 


project will be outlined. 


Introducti 


It wasn't long after amateurs started 
beta testing the TAPR TNC-1 that it 
became apparent to many that there was 
trouble looming on the horizon. Even in 
the earliest days, visionary amateurs 
could see that 1200 baud packet would 
not accommodate the large numbers of 
packeteers operating in heavily populated 
areas. Within a very short time the larger 
metropolitan areas of the country were, in 
fact, experiencing crowded packet 
channels. 


The adaptation of radios designed for 
voice use in the earlier packet radio days 
was acceptable. As the packet channels 
have become more crowded, the 
inefficiencies and economics of these 
voice radios have become a significant 
negative factor in packet radios growth. 
However, designing a_ better radio for 
packet use was far down the list of 
projects for TAPR to pursue. A glance 
through the Table of Contents of papers 
of earlier ARRL Networking Conferences’ 
will refresh memories of what, in those 
years, were the more pressing issues. 


During 1987 and 1988 the packet radio 


problem surfaced again and _ was 
discussed in earnest within TAPR. 
Finally, in hotel rooms at the /th 


Networking Conference, a decision was 
made to go ahead with a program to 
develop a radio designed specifically for 
digital use. This paper will outline the 
project to date. 


Andy Freeborn, NOCCZ 
President, Tucson Amateur Packet Radio 


Design Goal 


The purpose behind the packetRADIO 
project is to design a low cost, high speed 
rf box for the average Amateur. There 
were a number of design criteria set forth 
as goals from the start of the project. 
Figure A outlines the — current 
specifications of the radio. 


* Design a 9600+ high speed packet 
radio. Amateurs need faster local access 
than 1200 baud AFSK. While many will 
want to put the packetRADIO to work on 
their backbone links, it is the feeling of the 
development team that future network 
linking will be done at much higher 
speeds. By moving local network access 
to 9600 bit/s, our local packet frequencies 
will be better utilized. 


« Low cost. The design should be simple 
and easy to reproduce. By using simple 
FSK techniques that are already in use, 


Tucson Amateur Packet Radio - packetRADIO Project 


Figure A: Specifications _ 


General Power : +10 to +17 VDC 
Number of Channels : 1to4 
Frequency of Range : 144-148 MHz 
Transmitter Power Output : 25 watts into 50Q 
Mismatch : Stable into a VSWR of 3:1 
Modulation : 1200bps - 3 KHz deviation of 2200 Hz tone 
9600 bps - filtered FSK, +/- 3 KHz deviation 
Spurious output : -60 dBc 
Keyup time : Less than 1 millisecond 
Lineup : Modulated 45 MHz offset crystal oscillator mixed with 
receiver L.O. to produce output operating frequency. 
Receiver Sensitivity : -113 dBm (0.5 1V) into 50Q for 10° BER 
intermodulation : -70 dB 
Spurious response : -80 dB 


Time to carrier detect: 3 millisecond (9600 bps) 
15 millisecond (1200 bps) 
Lineup : FET preamp 
One Crystal-controlled L.O. per channel 
(for enhanced frequency stability). 
45 MHz (st I.F. 
10.7 MHz 2nd I.F. 
Linear phase response multi-pole filtering. 


Figure B : Front Panel (not to size) 


| TUCSON 
a AMATEUR 
XMT__1200 9600 PWR | PACKET 


RADIO 
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Tucson Amateur Packet Radio - packetRADIO Project 


such a radio will be compatible with other 
designs (TAPR [1], TPRS TexNet (2], G3RUH {3)). 
This also translated to less complexity 
than current commercial radios (i.e. no 
touch-tone, PLL, scanners, voice synthesizers, 
etc.) Figure B shows the front panel. 


* Fast turn around time between transmit 
and receive. This would allow the modem 
to operate as closely to 9600 bit/s as 
possible. The design now accommodates 
a one millisecond (mSec) turnaround 
compared to the average 150 mSec to 
400 mSec of commercial voice radios. To 
maintain this fast turnaround time, the 
team felt that the radio needed a 25 watt 
output to be acceptable for the widest 
variety of applications. Having an 
amplifier outside of the unit would again 
increase the turnaround time, which is the 
critical factor for better performance. 


* Include a 1200 baud AFSK modem to 
encourage the average Amateur to make 
the switch to the new design. This also 
allows compatibility with the existing 
standard. 


* The design should allow’ for easy 
modifications to obtain different bands 
and speeds (i.e. 220 MHz and 19.2 Kbit/s). 
The design should also allow full-duplex 
operation. 


¢ A number of items were included on the 
wish list : 
* Enhanced TNC built into the design 
which could also control the radio. 
* 220 MHz capability in the initial test 
units. , 





The TAPR_ packetRADIO 
controlled, 2-meter four frequency radio 
designed specifically for 1200 and 9600 


is a_ crystal 


bit/s packet operation. The TAPR radio 
employs pin diode switching and an offset 
transmitter oscillator to provide fast turn- 
around between transmit and receive. A 


block diagram of the radio is shown in 
Figure C. 


Starting at the antenna : 

The antenna is connected to a 
lowpass filter which attenuates’ the 
harmonics of the transmitter and provides 
high frequency selectivity for the receiver. 
The output of the lowpass filter is 
connected to the pin diode switch. This 
switch provides the transmit/receive P- 
switching in the transceiver. A pin switch 
allows fast switching between transmit 
and receive. 


Following the receive path: 
The received signal from the pin 
switch is connected to a 2-pole LC filter 
providing RF selectivity for the receiver. 


A FET preamp follows the LC filter 
providing a nominal 10 dB of gain anda3 
dB noise figure with a +30 dBm third order 
intercept point. The FET preamp output is 
fed to a 3-pole helical resonator which 
provides additional RF selectivity. The 
helical resonator output is fed to a FET 
mixer which provides a nominal 15 dB of 
gain with a +30 dBm intercept point. 


The 45 MHz IF output of the first mixer 
is fed to a 2-pole Piezo technology model 
2844 crystal filter. The crystal filter 
provides selectivity to protect the backend 
of the receiver. By using a crystal filter at 
this point in the receiver, the intercept 
point of the overall receiver is set by the 
preamp and mixer intercept points. The 
overall intercept point of the front end to 
the mixer output was measured to be -2 
dBm. This intercept point provides better 
than 70 dB IM protection to the receiver. 


The output of the 45 MHz crystal filter is 
fed to a Signetics NE605 IC which 
provides the second mixer, second local 
oscillator, 10.7 MHz IF amplifier and 
discriminator. The first 10.7 MHz crystal 
filter is a 4-pole Piezo Technology model 
5182. The second 10.7 MHz filter is a 2- 
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pole Piezo Technology model 2195. The 
combination of the 45 MHz and 10.7 MHz 
crystals provide tight selectivity for good 
adjacent channel protection with a flat 
group delay response. 


Data carrier detect is provided from the 
RF level circuits of the NE605. A front 
panel control is provided for the operator 
to set the sensitivity level for the DCD. 


The discriminator output of the NE605 is 
connected to the 1200 and 9600 bit/s 
modems. Each modem then provides the 
appropriate received data stream to the 
TNC interface. 


Local Oscillator: 

The local oscillator board provides a 
local oscillator signal to the receiver and 
the transmitter. Four crystal oscillators 
are provided for up to four channel 
operation. The oscillator also acts as a 
tripler providing a 33 to 34.333 MHz drive 
signal to the tripler. The tripler takes the 
oscillator/tripler signal and multiplies it to 
the 99 to 103 MHz range. 


The buffer amplifier provides gain to the 
99-103 MHz signal to provide a nominal 
+10 dBm signal out of the LO board. The 
power splitter divides the RF output of the 
lo board equally between the receiver and 
the transmitter. 


Exciter: 

The exciter board contains a 
frequency modulated crystal controlled 45 
MHz offset oscillator. The modulation 
input for the oscillator is provided from the 
digital board transmit modem. The 
transmit modem contains a FIR filter to 
filter the 9600 bit/s transmit data. In the 
1200 bit/s mode, the transmit modem 
uses the same ROM containing the 9600 
bit/s FIR filter to generate the 1200 and 
2200 Hz tones. The output of the 45 MHz 
oscillator is mixed with the output of the lo 
board in a NE602 mixer IC. 


The 144-148 MHz signal out of the 
mixer is filtered in a 2-pole LC filter and 
then amplified using two MMIC amplifiers. 
The output of the MMIC amplifiers is then 
filtered in a 2-pole LC filter and sent to the 
PA board. 


The exciter output is amplified by a 
Toshiba S-AV7 power amplifier on the PA 
board and then routed to the pin switch. 





The 1200 and 9600 bit/s modems 
designed for the TAPR packetRADIO are a 
culmination of years of experiments with 
1200 and 9600 bit/s amateur packet 
operation. The 1200 bits modem 
incorporates all the information obtained 
from the TAPR TNC-1 and TNC-2 EXAR 
2211 receive modem tests [4]. The 9600 
bit/s receive modem __ incorporates 
experience from the TAPR [1], TPRS 
TexNet [2; 5], G3RUH [3], and GRAPES [6] 
modems into a low cost, high 
performance FSK receiver. The selection 
of flat group delay filters in the IF of the 
packetRADIO simplifies the design of the 
9600 bit/s modem by not distorting the 
data signal in the receiver IF filters. 


In the 9600 bit/s receive mode, the radio 
discriminator output is sent to post 
detection filters and a limiter. In the 1200 
bit/s mode, the discriminator output is de- 
emphasized and detected in an EXAR 
2211 IC. The limited data from each 
modem is then sent to the digital board 
where clock is recovered from _ the 
received data stream. The reclocked data 
is then sent from the digital board to the 
TNC. The digital board also provides 
selectable rf or digital DCD. 


The transmit modem incorporates digital 
signal processing (DSP) techniques to 
generate the filtered FSK signal for the 
9600 bit/s modem and to generate the 
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tones for the 1200 bit/s modem. This 
creates a modem which only requires 
setting the deviation in the transmitter. 


The digital board contains the TNC 
interfacing circuitry. It also provides the 
transmit time-out function, data and 
control lines to and from the TNC and 
radio, and clock generation circuits used 
by both the radio and transmit modem. A 
16 and 1 times clock is sent to the 
transmit modem along with the transmit 
data to operate the transmit ROM. The 
transmit ROM contains a finite impulse 
response (FIR) filter which filters the 
transmit data in the 9600 bit/s mode. The 
transmit ROM also contains a 1200 and 
2200 Hz tone generator for use in the 
1200 bit/s mode. 


Beta-Testing 


As with previous TAPR projects, Beta 
testing will be an important part of the 
development process. Local Beta test 
coordinators will act as spokespersons for 
their test group. This procedure was used 
in the 1983 Beta test of TAPR's first 
packet controller. The end result was the 
TNC-1 design. To help facilitate 
communications, a special section will be 
made available to the coordinators on 
Compuserve's HamNet. This private area 
will help us detect problems and possible 
solutions much quicker than by mail. It 
will also allow’ information to be 
disseminated to local packet networks 
quickly. 


Initially the design team had hoped to 
have a 2 meter and 220 MHz radio 
available for testing, but due to time 
constraints, beta testing will only be done 
with 2 meter radios. Many groups have 
voiced interest in experimenting with 
higher frequencies and speeds during the 
testing period and the design team hopes 
that these groups can further add to the 
design of the packetRADIO. 


This project is the most complex TAPR 
has ever undertaken, so to help speed up 
the testing period the units will be wired 


and tested. There are no plans to 
produce kits. By doing this, we hope to 
shorten the time it will take for 


manufacturers to have units available in 
the market place. If in the end, this allows 
the average packet enthusiast to enjoy 
true high speed digital communication at 
reasonable cost, then Amateur Radio will 
once again have contributed to advancing 
the state of the radio art. 


Notes : 


1. Conference proceedings are available from 
the ARRL 225 Newington CT 06111. 
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Amateur TCP/IP in 1989 


Phil Karn, KA9Q 


ABSTRACT 


This paper is a report on the status of the KA9Q Internet Protocol package, also 
known as NET. Most of the items proposed in last year’s paper have been completed, 
and additional features have also been implemented by the author and other contribu- 
tors. The use of TCP/IP with the WA4DSY 56kb/s modems is also discussed, along 
with some ideas on channel access methods that would improve the efficiency of these 


modems. 


Introduction 


Amateur TCP/IP continues to grow in 
popularity. In ampr.org, the portion of the 
ARPA Internet name space reserved for ama- 
teur packet radio, there are now over 2300 
registered IP address assignments in 29 coun- 
tries. NET/ROM networks as well as ‘‘plain” 
AX.25 paths are being used to carry IP 
datagrams. Most of this activity uses convention 
1200 baud modems, but higher speed operation 
with WA4DSY 56 kbps modems is also growing. 
A newsletter edited by Rich Vitello WAILEQU, 
‘The New England TCPer’’, is devoted to ama- 
teur TCP/IP operation. 


NOS — Software Restructuring 


| have completed the internal restructuring 
of the NET software described in last year’s 
paper. The original version, on which the 
‘‘Dayton’’ releases 890421.0 and .1 from 
N3EUA are based, used a commutator loop 
structure. External events such as packet 
arrivals and protocol state changes, made 
‘“‘upcalls’’ to functions within each application 
that did the actual work. Applications therefore 
had to be structured as state machines driven by 
external events (the upcalls), and this became 
very clumsy for the more complex applications 
such as the FTP client. 

The new version, referred to as ‘“NOS”’, is 
internally quite different as it supports internal 
multitasking. Each task is a logically separate 
program. Tasks have private stacks; in C, that 
means they have their own automatic variables. 
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On the other hand, they share the same set of 
Static and global variables. Tasks may block, 
that is, they can call a special system function 
that does not return until a specified event hap- 
pens. Whenever a task blocks, it is “‘put to 
sleep’’ and the system picks another to run until 
it too blocks. Tasks may wait for events that 
are signaled by hardware interrupts (e.g., when 
a packet arrives or a key is pressed) or software 
(e.g., messages from other tasks.) 


The kernel (that part of the system that 
controls the running of tasks) is non preempt- 
ing. That is, when a task gains control of the 
system, it continues to run until it explicitly 
relinquishes control by waiting for an event. 
This is in contrast to the preempting kernel 
commonly found in timesharing systems, where 
a running task can be suspended and another 
run at any time by an interrupt. The choice of a 
non preempting kernel is an important feature, 
since it avoids a whole class of potential bugs in 
which shared data being modified by one task is 
left in an inconsistent state when preemption 
occurs. The only situation that requires care Is 
the modification of global data by an interrupt 
handler, since interrupts can happen at any 
time. There are only a few such situations 
within NOS, and the tasks avoid conflicts by 
temporarily disabling interrupts whenever the 
shared data is examined or modified. 


The main drawback to the non-preempting 
approach is poorer real-time response; even if 
an external event (e.g., a packet arriving) makes 
a task runnable, it will not get control! until the 


currently running task gets around to giving up 
the system and any other runnable tasks have 
had their turns. In a networking system like 
NET, the only significant ‘‘real time’’ require- 
ment is that incoming data not be lost, so 
incoming data is buffered al interrupt time until 
the main network task can get a chance to pro- 
cess it. This only requires that hardware inter- 
rupts not be disabled for excessive periods and 
that the network task gain control often enough 
to empty the incoming buffers before they 
overflow. However, the tasks that make up 
NET seldom run for more than a few mil- 
liseconds at a time before blocking, so this is 
not much of a concern. With the exception of 
the “‘hs’* HDLC driver discussed later, the only 
Significant latencies occur when a task reads or 
writes a block in the MS-DOS file system. 
Because the MS-DOS file system is synchro- 
nous, NET cannot run during disk I/O. Fixing 
this would require rewriting substantial portions 
of MS-DOS and the ROM BIOS, and is outside 
the scope of the project. 


The “‘memory model’’ used by NET on 
the IBM PC also changed during the conversion 
to NOS. For some time, the ‘“‘medium model’”’ 
(large code, small data) was used; now the 
‘‘large model’’ (large code and data) is used, 
allowing the use of more than 64K for data 
buffering. Although the need for more data 
space rose gradually as the package grew, the 
main impetus for change was the need to allo- 
cate a stack for each task. The conversion to the 
large data model was much easier than I had 
expected. The only module affected was the 
Storage allocator, the only portion of the pack- 
age that deals with data blocks larger than 64K. 
The enlargement of block size fields From 16 to 
32 bits and the addition of the ‘‘huge’’ keyword 
to various pointers was the only change required 
to the allocator. 


One problem that is still present in NOS is 
the need to keep careful track of allocated 
Storage blocks. Unlike a conventional time shar- 
ing kernel (e.g., UNIX), storage allocated by a 
task in NOS is not automatically freed when the 
task completes. Tasks frequently allocate storage 
(e.g., a data buffer) and immediately pass it off 
to another task, and | considered it too time- 
consuming to have to keep careful ownership 
records for each allocated block. Dynamically 
allocated storage is also used in global data 
structures (e.g., TCP control blocks) that do not 
necessarily belong to any particular task, and 


this would complicate the record keeping even 
more. 


Shortly after creating NOS I decided to 
switch to the Borland Turbo-C compiler as the 
primary compiler for the PC version. This 
change was made for several reasons: the wider 
availability and lower cost of Turbo-C, making it 
easier for others to configure and modify the 
code; fewer compiler bugs, especially in the new 
ANSI C features; better support for PC-specific 
hardware functions, allowing the elimination of 
some assembler code from the package; and the 
provision of an assembler with a built-in macro 
allowing C-callable assembler functions to access 
their arguments in a memory-model indepen- 
dent fashion. 


Sockets 


Very little was changed inside the protocol 
modules per se in the NOS conversion. A new 
module was instead placed on top of the exist- 
ing TCP and UDP modules, implementing an 
application programming interface based closely 
on the “‘socket’’ mechanism in the Berkeley 
version of UNIX. The socket code provides the 
upcalls required by the existing TCP and UDP 
code . These upcall functions signal events 
internal to the socket module so that the socket 
primitives (e.g., send or receive data) can block 
appropriately. Applications using the socket 
interface do not need to provide any upcall 
functions. 

The Berkeley socket interface supports 
protocols besides those of the Internet. It was 
therefore fairly easy to allow applications to 
access the AX.25 and NET/ROM protocols by 
creating two new ‘“‘address classes’’, AF _AX25 
and AF NETROM. Either the virtual-circuit 
mode (using I frames) or the datagram mode 
(using UI frames) can be selected. 


Although the socket interface follows the 
Berkeley UNIX model as closely as possible, 
there are some unavoidable differences. The 
most important difference is that socket descrip- 
tors in NOS are distinct from file descriptors, 
unlike Berkeley UNIX where they occupy a 
common set of integers. In other words, socket 
descriptor 1 does not refer to file descriptor 1, 
and the regular file I/O functions readQ) and 
write() cannot be used on sockets. All socket 
I/O must be through the recv(), send() and 
related functions. There is also a_ special 
close_s() call for sockets, since the regular 
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close() function expects a file descriptor. Emu- 
lating the Berkeley model more closely would 
require either a major internal change to 
Borland’s standard C library or an independent 
reimplementation, and these changes could not 
be applied very easily to non MS-DOS environ- 
ments. 


All of the applications in NET have been 
rewritten to use sockets. In many cases the code 
became considerably simpler and smaller, partic- 
ularly in the more complex applications such as 
the FTP client. The simpler programming style 
made it possible to add features to the clients 
relatively easily; for example, the FTP client 
now prompts for user names and passwords dur- 
ing the login sequence, and it automatically 
suppresses echoing of the password as it is typed 
in. The user may now ‘‘type ahead”’ a series of 
commands to FTP without having to wait for 
each transfer to complete first. 


Domain Name Service 


Another feature that was added after the 
conversion to NOS is domain name support. 
The original version of NET relied on a local 
table of host names (stored in the file 
/hosts.net) to translate machine names (e.g., 
ka9q.ampr.org) to numerical IP addresses. This 
technique was originally used by all of the sys- 
tems on the ARPA Internet, but as the net 
grew this method rapidly began showing signs of 
Strain. 


The standard method now used in the 
Internet for name-to-address translation is the 
‘*domain name system” that consists of a distri- 
buted hierarchical database and servers that pro- 
vide access to this data. Names in the domain 
name system are hierarchical, with the top level 
on the right. Levels in the hierarchy are 
separated by periods, and the system allows 
delegation of naming authority to a different 
entity at each level. It is important to under- 
stand that a domain name does not say “any- 
thing* about the geographic location of the sys- 
tem being named, and it is even more important 
to understand that *the individual components 
of a domain name do not constitute a route to 
that system*. The only purpose of the domain 
system is the hierarchical division of the name 
space along administrative or political lines; 
routing is an entirely separate function that 
belongs down in the network layer. 
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The NOS version includes a domain client 
only; that is, it requires Internet access to a 
server running on a different type of system in 
order to work automatically. However, 
responses from the servers are stored locally in 
the file /domain.txt and reused, and the user 
may add entries to this file manually if a domain 
server is not available via the net. 


The domain name resolver is a good 
example of a feature that was fairly easy to add 
to NOS but would have been quite difficult to 
add to the old version. Applications querying 
the domain system must wait for a response. 
Doing this in the old version would have 
required additional states in the application 
represenling domain server response waits, 
while in NOS the change to an application was 
trivial because the resolve function blocks 
automatically. 


High speed TCP/IP 

Several groups have been using the 
WA4DSY 56kb/s modem with TCP/IP. Two 
methods of interfacing the modem to the host 
computer are being used. The first is the 
modified KISS TNC as pioneered by the 
GRAPES group in Atlanta. The PC-to-TNC 
link runs at 19.2 kb/s, so a single Station is 
unable to use the full channel bandwidth. 


The other approach uses the plug-in 
HDLC cards that have become available for the 
IBM PC over the past few years. Richard Bis- 
bey, NG6Q, and Art Goldman, WA3CVG, have 
written a driver for the ‘‘Eagle’’ card, a surplus 
8530 adapter card. Their driver makes use of 
the Eagle card’s DMA feature, but unfor- 
tunately DMA is not supported on all of the 
newer HDLC cards such as the Digital Radio 
Systems (DRSI) PCPA. I have therefore written 
the ‘‘hs’’ driver that uses the PCPA (or Eagle 
card) in a programmed I/O mode; that is, the 
host CPU copies each byte to or from the dev- 
ice as required instead of relying on DMA 
hardware. Both drivers work, but mine requires 
an essentially dedicated system; whenever the 
modem is active the system “‘locks up” and is 
unable to do anything else but service the 
modem. 


The ‘‘Awesome I/O” interface card 
designed by K3MC represents the best way to 
interface a fast modem to the IBM PC. It can 
buffer individual characters on its own, so the 
host PC need deal only with complete packets, 


which have much looser real time requirements. 
When the I/O card services the modem the host 
PC is free to respond to other interrupts. This 
will effectively eliminate the need to dedicate a 
PC to handle the modem, and it will allow mul- 
tiple modems to be handled on the same sys- 
tem. 

The network configurations at KA9Q and 
WBOMPQ consists of ‘‘stripped**> PC/XTs that 
operate as dedicated IP routers (packet 
switches) between local Ethernets and _ the 
56kb/s packet radio channel on 220.55 MHz. 
The theoretical throughput for a file transfer 
over this path ts about 5700 bytes/sec, assuming 
a data packet size of 1400 bytes, a modem 
keyup delay of 15 ms, 56. bytes” of 
TCP/IP/AX.25 protocol overhead, and ‘“‘stop 
and wait’’ operation of TCP. It is interesting to 
note that the 15 ms modem keyup delay 
accounts for about twice as much overhead as 
the three protocol headers combined. 


However, the actual throughput between 
PC/ATs is only about 3200 bytes/sec. There 
are two reasons for this. A minor cause is occa- 
sional TCP retransmission caused by link noise, 
but the major degradation is caused by the ina- 
bility to overlap packet transmission or recep- 
tion at each site with disk I/O due to the stop- 
and-wait mode in which we operate TCP. This 
latter reason is the main one, but we have 
found that stop-and-wailt mode is necessary to 
prevent collisions between data packets and 
their acknowledgements on the radio channel 
that would degrade throughput much more 
severely. 


Collisions — Again 


These collisions can occur even without 
hidden terminals on the channel because the 
modems take a finite amount of time to key up 
or to recognize that another modem has keyed 
up, and these delays create ‘“‘collision win- 
dows”. Fixing this problem (which occurs on 
1200 baud channels too) is a major challenge to 
amateur packet radio, and I have been investi- 
galing two possible solutions to the problem. 


The first approach is collision detection, 
the theory being that collisions aren’t so bad if 
you can detect them quickly enough to abort a 
transmission before it has wasted much channel 
time. The colliding transmitters then delay for 
random intervals and again attempt to transmit 
their packets. If another collision occurs, the 


transmitters repeat the procedure with random 
delays chosen from ever-increasing intervals. 


This is the approach used with Ethernet, 
also known as IEEE 802.3. Ethernet has been 
shown to be very stable even under pathological 
overload because of its collision detection 
feature. Useful throughput can be well above 
90%, depending on the length of the cable and 
the size of the packets, with the _ better 
efficiencies coming from shorter cables and 
longer packets. 

Collision detection is fairly easy to do on 
coax because of the relatively low attenuation. 
The much larger difference between transmitted 
and received signal levels in radio effectively 
makes collision detection impossible on a sim- 
plex radio channel. However, collision detection 
is possible through a repeater. If a user station 
operates in full duplex, it can compare its own 
signal heard through the repeater with the 
transmitted data. If no errors are seen, then the 
transmilting station can feel confident that the 
packet was not interfered with. 


Implementing collision detection with the 
WA4DSY modems requires a repeater that can 
pass the wideband signal the modem produces 
with a minimum of distortion. One way to do 
this is with a linear translator similar to the tran- 
sponders carried on the AMSAT communication 
satellites. A translator bandwidth of 100 KHz 
would be enough to accommodate the 75 KHz 
wide 56kb/s signal with guard bands on each 
side to avoid the phase distortion at the edges of 
the translator's bandpass filter. As with a satel- 
liie transponder, this translator should operate 
in a crossband mode in order to make full 
duplex operation at the user stations relatively 
simple. 


There is another approach to the collision 
problem that also deserves investigation: token 
passing. This technique requires considerably 
more complex software algorithms than collision 
detection, but it has the advantage of being 
usable on a simplex radio channel with no extra 
hardware. The IEEE 802.4 token-passing bus 
standard may be useful as a startling point, 
though a radio channel would be much more 
complex than the wire bus because of hidden 
terminals and higher noise levels. The model 
here is that of a voice round table; stations pass 
the token (the right to transmit) around a list of 
stations, with periodic pauses to allow new sta- 
tions (“breakers”) to join the logical ring. To 
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minimize the overhead spent on token passing, 
Stations should remove themselves from the 
logical ring when they do nol expect to send 
data for a while. 
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ABSTRACT 


This paper describes the design and implementation of a method for providing 
upper-layer OSI services on top of a TCP/IP/AX.25 protocol stack. The tools for 
the project include the KA9Q Internet package in common use today in amateur 
packet radio, and ISODE, an ISO development package designed for wire-based 
networks but modified for packet radio use. The method used is described in 
DARPA/Internet RFC-1006 and is a standard for those in the Internet community 
who implement ISO protocols using TCP/IP based networks. 


The paper first describes the network architecture of RFC-1006 and the basic sce- 
nario surrounding the implementation. A description of the implementation fol- 
lows as well as plans for future development. The paper ends with a conclusion 


and a list of references to recent work. 


Introduction 


Packet radio networks have evolved from 
simple signaling systems to complex 
structures of communication § using 
multi-layered protocol design. In many 
ways the evolution of packet radio com- 
munication has paralleled the evolution 
of data communication over wire and 
other land-based media. There have 
been periods of experimentation followed 
by periods of standardization during 
which more and more users of the net- 


work have contributed to its technical 
progress. 


We are now in a rather special period. In 
parallel with the debate going on in our 
governmental, educational and commer- 
cial institutions on the merits of OSI ver- 
sus TCP/IP, a similar debate has already 
started in our amateur ranks. 


The point of this paper is not to argue for 
one or the other sides of this debate. 
Rather we wish to report on some results 
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we have achieved using what we consider 
the best of OSI and TCP/IP in their cur- 
rent form as the basis for amateur packet 
radio. 


We have done this according to RFC- 
1006, also described in [RoseCass], a 
DARPA/Internet document, describing a 
method for achieving upper-layer OSI 
services on TCP/IP networks using the 
KA9Q Internet package along with a 
popular and publicly available implemen- 
tation of the ISO specified OSI upper lay- 
ers, ISODE. The KA9Q software is well 
known to the amateur packet radio com- 
munity, but the ISODE package needs 
some introduction. ISODE stands for 
"ISO Development Environment." It pro- 
vides the functionality for services at lay- 
ers 5, 6 and 7 (session, presentation and 
application) of the OSI reference model 
while leaving the lower layers (transport 
and below) to native or pre-existing im- 
plementations on the host computer. For 
a detailed description of the OSI stack 
and the ISO protocols, see [Tanen]. On 
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Ethernets and other wire-based net- 
works, ISODE has been married success- 
fully to various lower layer implementa- 
tions, such as X.25 and foremost to 
TCP/IP. Thus ISODE has been used to 
foster a transition from DARPA to OSI 
applications and as a method for both 
worlds to co-exist. It was only a matter 
of software development to realize this 
marriage in amateur packet radio. 


Most of the debate on the merits of OSI 
versus TCP/IP in the amateur communi- 
ty have centered on the lower or middle 
layers (network and transport.) It seems 
to us that the promise of OSI is in the 
upper layers, particularly in the richness 
of applications which have been recently 
defined and proposed by the ISO and 
other international bodies. Applications 
such as File Transfer Access and 
Management (FTAM), Message Handling 
Service (X.400) and Virtual Terminal 
seem to offer levels of functionality yet 
unavailable in the DARPA suite of appli- 
cations (FTP, SMTP and Telnet) and may 
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Figure 1: RFC-1006 as implemented with ISODE and the KA9Q 


Internet package. 
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offer the amateur community useful new 
services. In any case, we will never find 
out the truth of these claims for OSI un- 
less we begin to experiment with these 
protocols. 


The Scenario 


According to RFC-1006, OSI services are 
achieved atop a TCP/IP network by es- 
tablishing a Transport Service Access 
Point or TSAP upon which one then 
builds the session, presentation and ap- 
plication protocol agents prescribed by 
the ISO. The simplest way to do this, ac- 
cording to the RFC, is to encapsulate the 
least complicated ISO Transport Protocol, 
commonly known as TPO (CCITT X.224 
Class 0), inside TCP. The transport pro- 
tocol TPO requires the network service 
beneath to be reliable in an end-to-end 
sense. This means that the network 
guarantees that the packets on the re- 
ceiving end are ordered in the same way 
as they were on the sending end before 
they are delivered to the network user, or 
in this case, the transport entity TPO. 
Fortunately, the combination of TCP and 
IP do exactly that. They provide a "virtu- 
al circuit’ network upon which upper 
level services can be built. (See Figure 
1.) Instead of thinking of TCP as analo- 
gous to the OSI Transport Level and IP 
to the OSI Network Level, RFC-1006 
asks us to consider the combination of 
TCP and IP as providing a connec- 
tion-oriented Network service similar to 
the service provided by the ISO protocol 
X.25. 


Practically speaking, this scenario can be 
realized by using any implementation of 
TCP/IP with the proper programming in- 
terface to the ISODE software package 
which contains a TPO implementation 
and a socket interface to TCP. Since the 
new KA9Q Internet software [Karn 88] 
(often referred to as NOS) provides 
TCP/IP and a socket interface for build- 
ing new applications, the "construction 


job" was relatively easy. From the point 
of view of ISODE, the KA9Q software 
provides an OSI-like connection-oriented 
network service, and from the point of 
view of the KA9Q software, ISODE is just 
one more application using its socket in- 
terface. 


We had to make a number of design deci- 
sions when we started this development; 
some of them were forced on us, others 
were made for the sake of modularity. 
First, we had to port NOS from MS-DOS 
to UNIX!. The size of ISODE in memory 
was so large, that any hope of running 
the ISO protocols from this package on 
MS-DOS was abandoned. This is of 
course a major disadvantage. Not every 
amateur has the luxury of a computer 
running UNIX in his shack. On _ the 
other hand, UNIX is starting to appear 
more frequently on personal computers 
and, with the popularity of the new 
80386 machines increasing, it seems that 
UNIX may become a standard PC operat- 
ing system in the future. UNIX provides 
a process address space large enough to 
hold the ISODE implementations of the 
ISO protocols we wished to use because it 
offers paged virtual memory. ISODE is 
written in C and meant to be run in 
UNIX environments, so it was a natural 
decision to change to UNIX despite the 
fact that UNIX is not yet popular among 
amateurs. It is perhaps a significant 
point about this particular implementa- 
tion of ISO protocols that their size dic- 
tated a change in operating system envi- 
ronment. It seems characteristic of the 
ISO protocols in general that full imple- 
mentations grow to rather huge sizes. 
Whether this size is necessary for any im- 
pene is the subject of another de- 
ate. 


Once done, the choice of UNIX as the op- 
erating system for our experimentation 
offered us some distinct advantages. 


1. UNIX ts a trademark of AT&T. 
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ISODE was already being run at our site 
over a number of different sub-networks 
such as the Swedish Telecom's X.25 
Public Data Network anda TCP/IP 
Ethernet local area network with a gate- 
way to the DARPA/Internet. Thus an 
AX.25 sub-network interface could be 
added in a modular way. 


Design considerations 


Although it would be possible to write a 
special driver for AX.25 that sits below 
the socket interface and the native 
TCP/IP code in a machine running 
Berkeley UNIX, this approach has some 
disadvantages. The main one being that 
computers running Berkeley UNIX are 
rather expensive. 


There are a few radio amateurs that own 
UNIX computers, but these are often 
smaller models, eg. 80386 machines. 
They usually run AT&T UNIX System V, 
that does not have TCP/IP except as an 
expensive add-on. 


An AX.25 driver for Berkeley UNIX has 
been written [Neuman], but there are 
some problems with that approach. For 
instance, the Berkeley TCP implementa- 
tion expects shorter response times than 
what may be possible to achieve on a 
packet radio link. 


The KA9Q Internet package [Karn 87], on 
the other hand, is written especially for 
use over packet radio. Its TCP imple- 
mentation does not have timeouts built 
in. It also includes new mechanisms for 
congestion control. This makes the 
KA9Q TCP implementation robust in the 
face of long outages and the heavy con- 
gestion one may experience on packet 
radio channels. 


Because the source code for the KA9Q 
Internet package is freely available we 
had another strong reason to choose it as 
the basis for this effort. 


122 


Porting NOS to UNIX 


We already had the pre-NOS KA9Q 
Internet package running on a Sun work- 
station, but unfortunately it did not pro- 
vide a network interface that we could 
use. It used a "commutator loop’ to 
switch between different tasks. This is 
far from transparent to the applications. 


However, the new version of the package, 
NOS, provided precisely what we needed. 
Its socket interface makes it much easier 
to write application programs for the var- 
ious networking protocols supported by 
the KA9Q package. 


As an initial effort, the NOS program 
was ported, with as few changes as possi- 
ble, to different UNIX systems. This was 
fairly easy to do on a Sun-3 running 
SunOS 4.0. On our 80386 machine run- 
ning UNIX System V release 3.2, howev- 
er, things turned out to be more problem- 
atic. 


There were three main problems. Firstly, 
a timer interrupt mechanism is needed. 
This can be implemented with UNIX sig- 
nals. The timer interrupt decides what 
granularity one will get in retransmis- 
sion timers, etc. Although getting a 
timer interrupt only once per second will 
work, one would like to have better reso- 
lution. On a Berkeley UNIX machine 
this can be done with the ualarm() sys- 
tem call. But UNIX System V alarm() 
provides a maximum granularity of one 
second. The solution to this was to let 
NOS create a child process that makes a 
poll) system call and then sends a signal 
to its parent. This system call can be 
made to sleep for times less than one sec- 
ond. Unfortunately, our System V ma- 
chine occasionally fails to catch the signal 
as it should, and terminates the program. 
This is yet unresolved. 


Secondly, the NOS program must get an 


interrupt when one or more characters 
are available. On SunOS 4.0, ttys are 
implemented as STREAMS drivers. This 
makes it possible to get a signal every 
time new data arrives. 


In the version of UNIX system V that we 
have this is not possible, since the serial 
line ttys are not implemented as 
STREAMS drivers. Instead, we had to 
resort to a loop that polls the ttys once 
every 10 milliseconds. Obviously, this 
causes a major performance degradation. 


Finally, to achieve its multitasking, NOS 
assigns a separate stack to each of its 
processes. These stack areas should be in 
the data segment of NOS to make it pos- 
sible to both read and write the stacks. 
This works on a MS-DOS machine and on 
a Sun-3, but on a Sun-4 and our 80386 
machine running UNIX System V, one is 
not allowed to move the stack pointer 
into the data segment. The only solution 
we see is to place the stacks in some 
spare area below the original position of 
the stack pointer, but above the heap. 


Link level interfacing 


We did some initial tests with ISODE 
over packet radio without modifying the 
ISODE source code. The FTAM client 
transmitted its IP datagrams on an 
Ethernet. The Ethernet packets were in- 
tercepted by NOS. It routed the IP data- 
grams onto the radio channel to another 
NOS program. This NOS program rout- 
ed the datagrams to the FTAM server 
over an Ethernet. 


Although this method works, it has some 
disadvantages. The end point machines 
are completely unaware that their IP dat- 
agrams are routed through a packet radio 
channel. Therefore the datagrams have 
sizes suitable for Ethernets, approxi- 
mately 1500 bytes. If these IP datagrams 
are sent in 256 byte AX.25 frames, they 
have to be segmented, which is some- 


thing that should be avoided. Also, the 
TCP implementation will timeout if the 
throughput worsens. 


Network level interfacing 


The problems described above made it 
clear to us that it was inefficient to use 
the KA9Q software as a IP router only. 
It must be used by the application pro- 
grams in an end to end sense. ISODE 
should use at least KA9Q TCP/IP as its 
reliable network service. 


There are several ways of implementing 
this. One could make the services provid- 
ed by ISODE (FTAM, VT, etc.) a part of 
the NOS program. But the program 
would become so big that it would not be 
possible to run it on an MS-DOS ma- 
chine. 


Furthermore, the multitasking in NOS is 
done non-preemptively. This means that 
every process runs without interruption 
until it needs to wait. This works very 
well with communication protocols, since 
they often need to wait. But there might 
be high level applications that do not 
wait as often. Typical examples of this 
are programs that search through large 
databases on disk or tape. It is not easy 
to make these and similar applications 
work well when the operating system 
scheduler is non-preemptive. 


The most obvious objection against mak- 
ing ISODE a part of the NOS program is 
that UNIX is already multitasking. 
Having a program that implements its 
—e adds unnecessary over- 
nead. 


Separate UNIX processes 


We decided to eliminate the multitasking 
in NOS by splitting it up into several 
UNIX processes. Our implementation, 
whose working name is NETNIX, is 
shown in figure 2. 
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All transport, network and link protocols 
in NOS are run in a background process 
on the UNIX machine. Another process 
handles input from the tty to which the 
TNC is attached. This process has only 
one tty to serve, so it can block indefinite- 
ly, instead of polling it every 10 millisec- 
onds. This eliminates one of the major 
problems with running the KA9Q soft- 
ware on System V machines. 


The application programs, such as FTP, 
etc., do indeed run as separate programs 
under UNIX. They communicate with 
the server program using normal UNIX 
System V shared memory and sema- 
phores, This interprocess communication 
can be made invisible to the application 
programmer. All he needs to know is 
how to use the socket interface, which he 
links into the program at compile time. 
This socket interface is similar to the one 
provided by Berkeley UNIX systems, but 
is implemented using the socket code in 
NOS. 
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Shared memory, semaphores 


All application programs and the server 
have access to a pool of shared memory. 
They allocate buffers (mbufs) from this 
pool and transfer the data by passing 
pointers to the appropriate buffers. The 
socket table and a few global variables 
are also kept in shared memory. 


When an application program makes a 
call to a socket interface function, such as 
socket() or connect(), it is executed in it: 
own process space rather than in the 
server process. Eventually there is a 
need to call some protocol specific func- 
tion, like open_tcp(). The application pro- 
gram then issues a remote procedure call 
to the server, telling it to execute the 
specified function with the specified pa- 
rameters. When the server has finished 
executing the function, it returns a value 
to the application program. The remote 
procedure calls are implemented by pass- 
ing pointers to buffers in shared memory. 


The main disadvantage with this imple- 
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Figure 2: Two application programs communicating using the NETNIX shared 
memory, semaphore and socket interfaces. 
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mentation is that all critical sections 
have to be isolated with semaphores. 
Otherwise strange things might happen, 
such as two processes trying to write to 
the same piece of memory at the same 
time. This extra overhead, and the fact 
that the protocols run in user space, forc- 
ing context switches, make the imple- 
mentation somewhat slower compared to 
native TCP/IP code on a Sun workstation, 
but it is still acceptable. 


Transport level interfacing 


ISODE has a modular interface between 
the session level protocol and the trans- 
port service. So, it would be possible to 
incorporate a TPO transport protocol into 
NOS or NETNIX. 


But unlike TCP, there is nothing to gain 
by trying to customize TPO for use over 
AX.25 packet radio links. The main pur- 
pose of TPO is to provide a transport ser- 
vice access point, it does very little else as 
a protocol. Thus, we can use the TPO im- 
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plementation just as it is included in 
ISODE. There is no pressing need to 
build our own OSI-conformant transport 
protocol on top of TCP/IP. 


Implementing protocols in the UNIX 
kernel 


The protocol handling in NETNIX is fully 
implemented in user space. In operating 
systems like UNIX one usually puts the 
communication protocols, at least up to 
the transport level, into the operating 
system kernel. If the implementation is 
done properly there is no need to use 
semaphores to prevent conflicts between 
different users. 


SunOS 4.0 and System V release 3 pro- 
vide a mechanism called STREAMS for 
adding functionality to a communications 
channel in a modular way. Once a 
STREAMS device driver is opened, it is 
possible to push modules on top of it. All 
data that is written to the device may 
pass through this module that can add or 
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Figure 3: TCP/IP and RFC-1006 implemented with STREAMS. 
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remove protocol headers. It is also possi- 
ble to send messages that are interpreted 
as specific commands to the modules. 
One may also build one’s own STREAMS 
drivers, which can multiplex in both di- 
rections. 


At the time of the writing this paper, we 
have finished an AX.25 STREAMS mod- 
ule. This module can be pushed on top of 
a STREAMS tty driver. The AX.25 mod- 
ule itself does not know how to write 
characters to a serial port. This is han- 
dled by the underlying tty driver. An 
ARP module and an IP module are also 
near completion. Eventually a TCP driv- 
er will be written. It will sit on top of all 
other modules and allow several user 
processes to access it by means of UNIX 
file descriptors. (See figure 3.) 


A Berkeley UNIX-like socket interface 
could be built as a set of library routines. 
These library routines would map the fa- 
miliar calls such as bind(), connect(), etc., 
to a series of commands to the TCP driv- 
er in the kernel. 


Conclusion 


We have described an experiment achiev- 
ing certain OSI services such as FTAM 
over TCP/IP/AX.25 packet radio links. 
We found that we could do this by modi- 
fying existing publicly available software. 


Thus, we have created a testbed where 
further experimentation with ISO proto- 
cols on packet radio networks can be fur- 
ther researched and developed. We ob- 
served, among other things, that there 
was more processing overhead for the 
ISO protocols than for the DARPA appli- 
cation protocols and we need to eliminate 
this processing bottleneck before we rec- 
ommend the everyday use of the ISODE 
part of our software. We do, however, 
believe that we have made the first step 
towards developing a usable OSI-confor- 


mant packet radio network?. 
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Abstract 
Most amateurs do not realize the impact 
that packet radio is having upon 


communications outside the amateur 
community. This paper discusses current 
packet experiments taking place over 
NASA's ATS-3 satellite with respect to the 
system's potential for providing low cost 
data communications to remote Pacific 
islands. 


Introduction 


With the passing of each year, many 
Pacific Islanders fall further behind the 
technology curve [1]. Distance education 
is commonly viewed as the best means 
for providing these islanders with a way to 
maintain self-determination and self-suffi- 
ciency in the global community of the 21st 
century [2:3]. A low-cost data network 
covering the Pacific Basin is very 
important for providing distance education 
(4). An integrated satellite-packet radio 
system offers one possible’ data 
communication solution [5]. 


ATS-3 


The ATS-1 and ATS-3 _ satellites, 
launched by NASA in 1966 and 1967, are 
convenient platforms for working on wide 


area network connectivity. ATS-1 is now 
in an unstable orbit that will cause it to 
move out of its Pacific footprint (for the 
second time) Guring 1990-91. ATS-3 is 
maintained at 105 degrees (+/- 1 degree) 
west longitude, with an orbit inclination of 
10.3 degrees as of January 1984 [6]. 
Figure 1 shows the Earth coverage for 
ATS-3. 


The ATS VHF repeaters have a 
baseband bandwidth of approximately 
9O0KHz. The repeater may be used for 
wide band data transmission using the 
entire repeater capability. Arbitrary 
channel assignments have been made so 
that the satellite can support multiple FM 
simplex voice channels [6]. 


Figure 1 : ATS-3 Footprint — 
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ATS-3 Packet Experiments 


The VHF communications transponder 


is an active frequency-translator limiting 
(Class C) repeater receiving at a frequency 
of 149.22 MHz and retransmitting the 
received signal at 135.6 MHz. Reception 
and transmission is through an eight- 
element phased array antenna. Because 
the IF amplifiers include automatic gain- 
control circuitry, and the final power- 
amplifier stages are operated in class C, 
the VHF transponder is best suited to re- 
laying one or more frequency or phase 
modulated carriers. [6; 7] 


PEACESAT 


Pan Pacific Education and 
Communications Experiments by Satellite 
(PEACESAT) was conceived in 1969 by 
John Bystrom, Communications Professor 
at the University of Hawaii. Bystrom’s 
primary goal was to have NASA allow 
Pacific Islanders free experimental access 
to ATS-1 when the satellite completed its 
scheduled NASA activities [8]. PEACESAT 
was the first project in the world in which 
the delivery of instruction by satellite was 
attempted. This project produced the 
world’s first satellite library network, the 
first international satellite network, and the 
first college credit course delivered by 
satellite [2; 9]. 


PEACESAT became an_ international 
Organization with the participation of 
Wellington Polytechnic (New Zealand) in 
1971. A cooperative satellite project 
between the University of Hawaii and the 
University of the South Pacific, with its 
main campus on Fiji, yielded a credit 
course in comparative Pacific education in 
1973. Several other institutions in the 
South Pacific area later joined the 
network. These schools included New 
Zealand’s Victoria University, the Papua 
and New Guinea Institute of Technology, 
and Hawaii Community College. 
PEACESAT is still active, and currently 
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interconnects institutions in about 20 
nations in the Pacific Basin and Rim with 
two-way communications [2; 9]. 


The dissemination of machine readable 
data to Pacific Islanders has been a 
PEACESAT goal for more than 25 years. 
The initial ground station designed and 
constructed by Professors Paul Yuen and 
Katashi Nose (KH6lIJ) of the University of 
Hawaii were used to demonstrate 
facsimile as well as voice communications 
as early as 1971 [10]. Teletype 
transmission via ATS-1 was demonstrated 
in 1973 [9]. However, comparatively high 
costs for data communications equipment, 
a lack of technical sophistication on the 
part of typical ground station operators, 
and the inaccuracy of noise-saturated 
data all contributed to the failure of the 
data communications side of the intended 
applications shown in Figure 2 to fully 
materialize [1]. 


The early 1980's saw a resurgence of 
interest in low-cost PEACESAT/ATS data 
communications. Knezek in Honolulu first 
successfully captured a file transmitted 
from Suva, Fiji through a modified Hayes 
Micromodem (Bell 103 standard), Kenwood 
phone patch unit, and ATS-1 satellite to a 
similar system attached to a Texas 
Instruments portable bubble memory 
terminal in May of 1980. Measured error 
rates of less than .4 percent for early 
transmissions were sufficiently 
encouraging to continue development of a 
messaging system based upon Apple Il- 
Micromodem technology [11]. This 
messaging system remained in use in 
Micronesia and the South Pacific until 
ATS-1 first drifted over the horizon in 
1985 [12]. 
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PEACESAT Project Report One : Early Experience. Honolulu: University of Hawaii, 1975, p. 13. 


Also during the early 1980's, common 
carrier (Telenet, Tymnet) domestic telephone 
access from Hawaii to new information 
services such as_ The _ Source, 
Compuserve, and the Dialog Bibliographic 
Retrieval System caused an explosion of 
interest in computer-based information re- 
trieval services among  PEACESAT 
members. Unfortunately, international 
telephone rates prohibited even those 
Pacific Islanders (other than Hawaii residents) 
with reliable telephone access from being 
able to take advantage of such services 
[1]. Empirical data gathered during 1984- 
85 showed that micro-to-micro 
communications via PEACESAT could be 2- 
4 times more economical for Pacific 
Islanders than direct telephone or Telex 
connection, 5-10 times more economical 
than one-day air service delivery of 
printed material or a diskette, and 30-70 
times more economical than telegraph 
transmission. [13] 


Jones’ suggestion to try packet radio 
was submitted as a proposal to PEACESAT 
In 1987. PEACESAT management 
endorsed the concept and determined the 
initial pilot project goal should be remote 
interactive access to the University of 
Hawaii computerized card catalog via 
ATS-3. As shown in Figure 3, the 
University of North Texas worked with the 
University of Hawaii to assemble a 


prototype hardware/software packet radio 
system which was used to demonstrate 
searches of Hawaii's card catalog, via 
ATS-3 from Texas, and vice-versa, by late 
1988 [14]. 





The current phase of North Texas 
packet activities commenced in January 
of 1989 with modifications to ground 
Station design. The basic premise was to 
design a modular low-cost station, from 
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Figure 3: ATS-3 Library Access _ 
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| eer , Figure 4 : Modular ATS Station 
would provide voice as well as data and 
be able to include other features as 


needed. | Transmit 


| Antenna 


Figure 4 shows a block diagram of the 
modular station design. A modular design 


is important since in normal installations 
these stations would not have the 
equipment necessary for on-site service in 
case of problems. If a problem occurs 
with a modular station, then the ground 
station operator can remove the problem 
oart and replace it with a backup. The 
problem part can then be sent out to be 
repaired and a new replacement sent. 
Figure 5 details the cost breakdown of 
such a station. 


The modular approach also enables the 
systematic upgrade of selected station 
components. For example, current testing 
is focused on the performance differences 
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Figure 5 : Satellite (ATS) Packet Radio System Components and Costs 





Satellite Ground Station Components 


Transmit Antenna (Circular Yagi, 13 db, 149 Mhz) 
Receive Antenna (Circular Yagi, 13 db, 135 Mhz) 


Antenna Stand 

Coaxial Cable & Connectors 
Coaxial Relay 

Transmit Amplifier (40 Watt in, 150 out) 


Receive Pre-Amplifier (GaAsFet 144-148 Mhz) 


Radio Transceiver (134-150 Mhz) 
Terminal Node Controller 


TOTAL 


between the Kantronics KPC 2400 TNC 
and the MFJ Model 1270B. The next 
round of tests are scheduled to evaluate 
the effects of using 22 element (13db) 


antennas vs. the 14 element (10db) 
antennas commonly installed. 
Substitutions in any (or all) modular 


stations can be easily achieved, should 
either of these theoretical enhancements 
prove to be worthwhile in practice. 


Recen sults 


Results published by Lorente, LU4DXT, 
in the 6th ARRL Computer Networking 
Conference [15] indicate that the AMD 
7910 demodulator used in the KPC 2400 
should be superior to the EXAR 2211 
demodulator used in the MFJ 1270B, at 
least in the noisy FM environment often 
encountered on ATS-3. Tests to date in- 
dicate that (once properly configured) the KPC 
TNC indeed improves performance to the 
point where 300 baud transmission can 
proceed without major concerns. It also 
appears that 2400 bps transmission on 
the KPC (using QAM) results in: 1) fewer 
retries than 1200 bps transmission on the 
MFJ, and 2) about the same ratio of 
successful packets to retries as does 300 
baud transmission with an MFJ Model 
1270B. These small improvements are 
important since SSB transmissions, which 
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improve performance, 
have not been possible. 


should greatly 


It is hoped that combining higher gain 
antennas (M2 Model C22s) with KPC 2400 
TNCs _ will achieve dependable data 
communications at 2400 bps. 


Future Plans 


We believe the next major enhancement 
to an ATS-3 packet radio system will take 
the form of digital (FSK) radios substituted 
for the current voice (AFSK) units 
commonly employed. The goal is to 
achieve a message forwarding system 
that can operate reliably, in an unattended 
mode, by using late-night (continental U.S.) 
hours which are currently little utilized on 
the ATS-3 satellite. Units such as the 
TAPR packetRADIO described in a separate 
paper of these proceedings appear to 
hold promise for 9600bps communication. 


Funding is being sought to conduct 
basic Pacific Basin local area network 
research. This research would outline 
potential LAN strategies and bring 2 or 3 
technicians from Tonga, Western Samoa, 
or American Samoa to North Texas for 
cooperative AIS-3 packet radio 
development. The Pacific International 
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Center for High Technology Research 
(PICHTR) has agreed to send North Texas 
personnel to the South Pacific for packet 
radio training during the summer of 1990, 
and is working with UNT to secure 
external funds for the cooperative devel- 
opment activities. 


nclusion 


It is important to bring the ATS-1 & -3 
data communications work of the past 10 
years into perspective. Just as many new 
developments from the amateur ranks 
have functionally equivalent counterparts 
in the commercial sector where large 
budgets are more common, so it is for 
ATS-3 packet radio developments. 
During recent years, NASA’s ATS-3 
control station at Malabar, Florida, has 
exchanged data with oceanographic 
research vessels and Antarctic research 
expeditions, via ATS-3, using Phase Shift 
Keyed (PSK) modems and minicomputers 
running DecNet communication protocols 
in full duplex, split channel operations. 
The cost of these ground stations is at 
least an order of magnitude (x10) higher 
than the amount paid for an ATS 
installation at a typical educational 
institution in a Pacific Island nation. Even 
if massive foreign aid could bring a NASA- 
type installation to every needy Pacific 
Island location, it is our opinion that it 
should not, because the resulting system 
would require even more massive 
amounts of external support to maintain. 
Just as foreign-subsidized automobiles 
often run for a year or two on a Pacific 
Island with a few miles of road, then rot 
after the first requirement for a major 
repair, SO might sophisticated 
telecommunications facilities quickly 
become non-functional in environments 
where access to running water and 
electric power cannot be taken for 
granted. Perhaps we should be teaching 
Pacific Islanders how to ride bicycles, 
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rather than how to drive cars, because 
bicycles are affordable, maintainable, and 
just as_ efficient transportation as 
automobiles for most Pacific Islander 
needs. Likewise, packet radio should be 
seriously considered as an alternative to 
more expensive, less maintainable data 
communication systems. 
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ARES/Data UPDATE: 
A PACKET RADIO DATABASE FOR EMERGENCY COMMUNICATIONS WITH CONFERENCE BRIDGE 
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1003 Belder Drive 
San Jose, California 95120 
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David Palmer, N6KL 
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N6KL @ KB60WT, CIS: 73357,3157 


INTRODUCTION 


ARES/Data is a multiple-connect, multiple-port specialized bulletin 
board system with a conference bridge that is tailored to store and retrieve 
basic information about people, places, or things in an emergency or disaster. 
The current program (Version 1.0) contains several enhancements not included 
in ARES/Data Version 0.1 [see Moerner, W. E., & Palmer, D. (1988), ARES/Data: 
A Packet Radio Database for Emergency Communications, Proceedings of the 
Seventh ARRL Computer Networking Conference, 141-144]. [Note: For those 
interested in the history of ARES/Data, see the above mentioned article and 
also see Moerner, W. E., Moerner, S., & Palmer, D. (1987), Family Information 
Database for Emergency Responders, Proceedings of the Sixth ARRL Computer 
Networking Conference, 131-141. ] 








New features added to version 1.0 (beyond 0.1) include: 


- Multiple ports (up to 4, with 8-32 simultaneous connects each) 
- Support for DRSI PC*PA packet adapters 

- Enhanced config file processing with startup files for each TNC 
- Update of selected field in a record 

- Import/Export facility 

- List range in addition to list all 

- Beacon facility 

- Download file facility from a public directory 

- Labels command, including a label for the message field 

- Separate paths for database, index files, public directory 

- Many enhancements for the sysop screen 

- Improved error handling of disk full and disk errors 


The key idea behind ARES/Data is that it allows tracking of any needed 
information that can be organized as four 20-character fields plus an 80- 
character message for each record. 


ARES/Data is a system designed for management of information during a 
widespread emergency that overloads normal communications channels. The 
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program is conceived to be flexible, so that it can be used without change for 
both small and large disasters to organize information about victims, 
evacuees, or even ham radio operators. Examples of situations in which 
ARES/Data could be used include: 


- Track victims of a multiple casualty incident sent to hospitals 

- Track ham manpower availability / assignments 

- Record evacuees and shelter enrollment 

- Track floats in a parade 

- Short-message database: Fieldl = To Field2 = From Msg = 80 char. message 
- House-by-House Damage Assessment 

- DX Spotting (!) 

- Etc.: |] 


ARES/Data SYSTEM OVERVIEW 


Briefly, ARES/Data may be regarded as a specialized, multiple-port, 
multiple-connect database with a specific command set tailored to the handling 
of information input, search, listing, and summary requests. In addition, the 
system provides a full-featured conference bridge so that all connected 
stations may converse conveniently with one another. 


The ARES/Data network is a star network with the ARES/Data database 
machine at the hub. It looks something like this: 


ARES/Data Database Machine 
| | 


] | I l 

Port A Port B Port C Port D 

| 1 | I 

I | | | 

radio radio radio radio 

PP Pp Pp PpPp P PP Pp P PP PP 


Each "P" represents a remotely-connected packet station which is connected to 
the ARES/Data database machine. All the remotely-connected stations have 
shared access to the data in the system. In particular, the packet operators 
can utilize two groups of functions provided by ARES/Data which are described 
in detail in this file: 


I. send/receive status requests and current information to/from the 
ARES/Data database station 

II. send/receive short messages to/from other remotely connected stations or 
the sysop (Conference Bridge) 


As can be seen, there are three major elements to the ARES/Data system: 
o ARES/Data software and database (at one centrally located computer) 


o Remote packet stations connected to the central node 
o Conference Bridge 
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The central element of the ARES/Data system is the ARES/Data database 
program running on an IBM Personal Computer or compatible. The ARES/Data 
program collects and collates current information about people (or other 
items) according to the needs of the incident, and maintains the database on 
floppy disk or hard disk at this central computer. The sysop at this computer 
can execute all database functions. 


If remote access is desired to the information in the database, this 
computer may be connected to a packet radio channel or channels through up to 
four ports, each of which can be either a TNC with WA8DED firmware or a DRSI 
PC*PA packet radio adapter. In this manner, other remote packet stations can 
connect to the ARES/Data machine and thus gain access to the stored 
information. This information can be updated or queried by the sysop or any 
of the remote packet stations that are all simultaneously connected to the 
main database station. 


At any time, the sysop and any of the connected stations can communicate 
with each other by using a simple "tell" command. This "conference bridge” 
actually implements a star-shaped network in which the central database 
station relays all of the message traffic. (As noted, the central element of 
the ARES/Data system is the computer on which the ARES/Data program is 
running. ) 


Hardware Requirements 


The ARES/Data program will run on any IBM Personal Computer or IBM- 
compatible system running DOS V. 3.2 or later. Although it can be run on a 
computer having about 400 KB of memory or more with at least one floppy disk, 
a hard disk is recommended as it increases the allowable size of the database 
and improves performance. [IBM is a registered trademark of International 
Business Machines Corporation. ] 


To enable the remote packet access features, the sysop also needs at 
least a (i) DRSI PC*PA packet adapter, cable, and transceiver or (ii) RS-232 
serial port, TNC containing WA8DED firmware (TNC-1, TNC-2, AEA PK-87, AEA PK- 
88), cable, and transceiver. NOTE: the remotely connecting packet stations 
may use ANY AX.25 TNC. 


DESCRIPTION and OPERATION of the ARES/Data SYSTEM V. 1.0 
The ARES/Data Program 


The ARES/Data software was written by W. E. Moerner, WN6I, and David 
Palmer, N6KL, with the ideas and support of a committee of hams from the Santa 
Clara County Amateur Radio Emergency Service (ARES). It is a copyrighted 
program, available without charge to anyone interested. The authors cannot 
and will not accept remuneration for this program which is provided as a 
public service only. The ARES/Data program is written in Turbo Pascal Version 
5.5, and uses Turbo Database Toolbox for management and indexing of its B-plus 
structured tree. [Turbo Pascal and Turbo Database Toolbox are trademarks of 
Borland International, Inc. ] 
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ARES/Data may be run in either of two modes: (i) stand-alone with no 
TNC support and no remote access, or (ii) by changing the configuration file, 
the program will control one or more TNCs to allow multiple, simultaneous 
remote connections. Use of WA8DED firmware with the central computer is 
necessary because WA8DED host mode is used for communication between the 
computer and the TNC. WA8DED firmware is currently available for the TAPR 
TNC-1 and TNC-2 as well as the AEA PK-87. We emphasize that NO REQUIREMENT IS 
PLACED ON THE OTHER TNC'S CONNECTED TO THE ARES/Data DATABASE MACHINE, except 
that they use AX.25 link-layer protocol. 


General Rules for Current Information Input/Search Requests 


All basic commands can be entered either at the main ARES/Data keyboard 
or at any one of the remotely connected packet stations. The operator at the 
main ARES/Data keyboard (the "sysop") has an additional set of commands that 
allow direct communication with the TNC, the printing of a log, backups, and 
disk report files. 


ARES/Data organizes the incoming data into "records", which can be 
viewed as a group of pieces of information about some particular person, 
place, or thing. Each record is given a unique "record number" by the 
program. Each record consists of four main items or "fields" plus a message 
item. The information in the four main fields can be used as keywords for 
searching as required. 


Syntax for Current Information Input 
fieldl,field2,field3,field4,message<cr> 
(<cr> means carriage return) 


To add a record to the database, the operator simply enters (in order) 
the four fields and any message, separating each field with a comma. Within a 
field, leading and trailing blanks are ignored, but imbedded blanks ARE 
significant. If no value is desired for a particular field, just skip the 
field by adding an extra comma. The database will fill that field with ten 
blank characters. 


Fields 1 through 4 


The four main fields are totally general. Each can have up to 20 
characters, with imbedded blanks. Entries can be in upper or lower case, or a 
mixture, but are converted to UPPER case before being stored in the database. 
The meaning of each field is defined at the beginning of the event depending 
upon the nature of the event. The sysop can issue a "labels" command that 
will give specific names to each of the four fields to help the operators 
remember what they mean. Similarly, the remote packet operator can type 
"labels<cr>" to see the current label definitions. 


Message 


MESSAGE is an optional, free-form field that can be up to 80 
characters in length. It could contain a message, a phone number, an address, 
or other information deemed useful for the incident. The distinction between 
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the "fields" and the "message" is that the "fields" are organized internally 
by the program so that the packet operator can request searches and summaries 
on the information in any one of the four fields. Searches and summaries 
cannot be performed on the information in the message field. 


Examples of Data Input with Sample Responses from ARES/Data 





85553195, joe, 12,sj34<cr> 
response-> 1040: data input accepted, #234. 


Johnson,Mary,93445,sj13, home 2333 Alsace Ln SJ 617-555-2368<cr> 
response-> 2134: data input accepted, #114. 


All of the input information is stored in the database as a record of 
the status and location of a particular person, place, or thing at a 
particular time and date. The time and date are added automatically by the 
ARES/Data program. Further STATUS INPUT packets for the same person, place, 
or thing will also be saved in the database. The time and date identifies the 
most recent information. 


Correcting and/or Updating Information 


Two options are available if incorrect information is entered into the 
database or if the information in a particular record has changed. 


Deleting an Entire Record 


You can ask the sysop to delete the bad entry by typing a message 
to him/her, such as: 


tell sysop ooops, typo. pse delete #234.<cr> 


OR, if the sysop has enabled the remote delete feature, a remotely connected 
packet station can delete this by using the delete command: 


d nnnn<cr> (where nnnn = record number) 


This function is always enabled at the sysop keyboard. Its use by remotely 
connected packet stations is controlled initially by the configuration file 
during program startup. Thereafter, the sysop can disable or enable this 
function as necessary. 


Changing or Updating a Particular Field of a Particular Record 





The syntax for updating fieldm of record nnnn is: 
/innnn,m=new text for fieldm<cr> 


For example, suppose it was desired to change the value in field3 of record 
235 to "shelter 9". This is done by typing: | 


#235,3=shelter 9<cr> 
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Note that when correcting or updating a single field like this, the time and 
date for the record are not changed. ARES/Data responds by showing the old 
values for record 235, along with the newly updated values. 


Requesting Information from the ARES/Data Database 


The packet operator can request several types of searches of the 
ARES/Data database. S/he can request a search for a specific value of any one 
of the four main fields. In this case, the ARES/Data program sends back to 
the packet operator a status report listing all entries in the database having 
the specified value for the selected field. In addition, the operator can 
request a "wildcard" search, which looks for any entries in a specific field 
that START with a particular string. The packet op can also request a summary 
for any one of the four fields, which is a list of the number of entries in 
the database for each distinct value of that field (see below). The operator 
can list single records in the database by specifying the record number. 


Syntax for Search Requests 


/1,value<cr> or ?1,value<cr> Searches for "value" in field 1 
/2,value<cr> or 72, value<cr> Searches for "value" in field 2 
/3,value<cr> or 273, value<cr> Searches for "value" in field 3 
/4,value<cr> or 274, value<cr> Searches for "value" in field 4 


This type of packet instructs the database to look for ALL entries with 
the same entry as "value" in the specified field. The string "value" must 
exactly match what was originally typed in for the selected field, with 
leading and trailing blanks removed, and without regard for case. The initial 
character of the search request can be "/" or "?" - use whichever is most 
convenient. The two formats are handled identically. A status report listing 
all information for each match is sent back to the requesting packet station. 
The first line gives the search value and the field number. At the end of the 
report, the line: 


"ARES/Data Search done at 1534, nn hits." 


is sent, which signifies no more information coming, and that "nn" matches (or 
hits) were found in the database. 


Wildcard Search or Partial Search 
The syntax for a wildcard or partial search is: 
/n,val*<cr> 

where "n'" is the field number, and "val*" indicates a search for all entries 
in fieldn that start with the characters "val". The response from the system 
is identical to that for an exact search request. This is very useful if a 
particular field has been defined to hold more than one piece of information. 
For example, suppose field 1 is defined to be "Lastname-Firstname" so that 


Bill Jones would be entered by the line: 


Jones-Bill, shelter3, OK, 444-555-1212, message<cr> 
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Without knowing Mr. Jones' first name, or whether his data was entered as 
"Bill" or "William," one can still search for him in the database by typing: 


?1,Jone*<cr> 


The database would retrieve all records whose first field began with the 
characters "JONE". 


Syntax for Summary Requests 
$l<er> produces a list of all distinct values 


for fieldl, with the number of entries in 
the database for each 


$2<cr> similar, except summarize on field 2 
$3<cr> similar, except summarize on field 3 
$4<cr> similar, except summarize on field 4 


A Summary Command is provided that prints a breakdown of the number of 
like-named items for any particular field. For example, suppose field 3 were 
defined to be the shelter name. After the packet operator types "$3<cr>", 
ARES/Data sends a summary on field 3, which may be interpreted as a list of 
shelters, with the number of people that have checked in to each shelter. 


Sample Output from a Summary Request 


Database summary for Shelter at 1455 on 23 


OAK GROVE 3 

PIONEERHS 20 
EASTVIEW 66 
SHLTR5 37 


ARES/Data done at 1456, found 4 distinct values, entire DB has 153 
records. 


Listing Specific Entries (Records) in the Database 
1 nnnn<cr> Lists record nnnn 


Each record is automatically assigned a unique record number for 
identification purposes. The response will be a short header showing the 
labels for the various fields, and then the complete information for record 
nnnn. 


1 nnn,mmm<cr> Lists records numbered from nnn to mmm 
1 all<er> List ALL records in the database. 
WARNING: be careful with this command, as it may cause a 
large number of packets to be sent on the channel. Stop 
an undesired "list all" by simply disconnecting from the 


ARES/Data machine. This will cause no harm. Wait a bit, 
then just reconnect. 
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Downloading Files 
To download a file from the database machine, type: 
get filename<cr> 


This facility is intended to be used and controlled by the sysop in the sense 
that s/he should tell the remote users what filename to download. There is no 
directory facility or anything like that, because such functions are handled 
better by a standard mailbox program such as BB (by AA4RE) or WORLI. One file 
that is provided with ARES/Data is an "info" file, which gives more 
information of interest to general users. If the sysop has copied this file 
to the public subdirectory, a station can download it by typing: 


get info<cr> 
Conference Bridge (Roundtable) 


This feature allows any connected station to send messages to other 
connected stations or to the sysop. The conference bridge illustrates how the 
ARES/Data system operates as a hub-oriented network, with all transactions 
passing through the central database station. 


Users Command 


The users command in the form "users<cr>" or “u<cr>" returns a 
list of the callsigns of packet stations currently connected to ARES/Data. 
The response is of the form: 


Users at WN6I-1 (AXO): N6KL W6BB-3 W6XYZ WB6MRQ-7 
Users at WN6I-4 (DRO): O:N6KL-3 1:N5BZK 3:AA4RE-12 


Note that there is one line for each port defined in the ARES/Data 
system; who is using which port can be seen. The callsigns used by ARES/Data 
for the verious defined ports do not have to be identical. After the database 
callsign, the port name defined by the sysop during startup is shown in 
parentheses. Note also that for the DRSI packet adapter, several radios and 
even several boards can be attached to the database machine. All the users 
connecting to the DRSI adapters are treated as being on one port of the 
ARES/Data network. To refer specifically to the user on DRSI sub-port 1, put 
a "1:" in front of the callsign: "1:N5BZK". In general, however, this is not 
really necessary, since as far as ARES/Data is concerned, "N5BZK" or "BZK" 
will do just as well (see below). 


Tell Command 


The Tell command allows connected packet stations to use ARES/Data 
as a conference bridge, or roundtable. The general format is: 


tell callsign message<cr> OR t callsign message<cr> 
For example: 
tell w6bb-3 The food truck just arrived at SJ12<cr> 
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The message "We have lots of people here at SJ12" is sent to the connected 
station W6BB-3 prefaced by a time stamp and the call of the station 
originating the tell command. In this case, if the tell command was sent by 
WOXYX, W6BB-3 sees: 


1230 W6XYZ> The food truck just arrived at SJ12 


It is not necessary to enter the entire callsign--just the suffix or 
some other substring will do. If several connected callsigns contain the 
substring, each station will get the message. The special callsign "*" or 
"all" is used to send a message to all connected stations. The special 
callsign "sysop" sends the message to the sysop at the ARES/Data database 
station. 


EXAMPLES OF HOW TO USE ARES/Data IN SPECIFIC DISASTER SCENARIOS 


One of the major virtues of this system is that the meaning of the 
stored information is not defined in advance. In this manner, an ARES/Data 
system can be left in unattended operation 24 hours a day, and then be put to 
use instantly, in a variety of ways, depending upon the particular disaster or 
emergency at hand. In a given event, the sysop can issue a "labels" command 
that gives particular meaning to each of the fields and the message, so that 
all know how ARES/Data is being used for that event. 


In an evacuation, you may want to keep track of evacuees at shelters. 
Then you may want the fields to mean: 


Name, Shelter, Status, PhoneNumber, Contact person. 


In a multiple-casualty incident, you may want to keep track of victim 
transportation. You may then define the fields to mean: 


Triage number, Sex/Age, Ambulance, Hospital, Condition. 


If you need to maintain a roster for a ham radio staffing situation, the 
fields could be: 


Call, Name, Location, Shift, phone number for cancellation. 


If you were in a disaster situation where damage assessment and damage 
reports were needed, consider having the following fields: 


Coded type of damage, Location, Number of injuries, Callsign, comment. 


There are many more possibilities, of course. This is why the exact 
definitions of the various fields are not defined in advance. In any given 
situation, more information than will fit into four fields and a comment field 
might be needed. However, on today's 1200 baud packet radio networks, not 
much more information per record can be accommodated without restricting the 
total number of records that can be handled in a reasonable time. 
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HOW TO OBTAIN YOUR COPY OF THE ARES/Data PROGRAM 


The ARES/Data program, a relative of and successor to the FINDER 
program, is available free of charge. The current version is 1.0, which 
operates as described in this paper. It is possible to download the program 
via CompuServe's HamNET in data library 9 and it is also available for 
anonymous FTP from the SanJose TCP/IP gateway as file ARESDA1O.ARC. In 
addition, a copy of the program along with the documentation is available for 
non-commercial, non-profit use from WN6I or N6KL by sending a blank, formatted 
5 1/4" (360 kB) or 3 1/2" (720 kB) floppy in a mailer with return postage 
stamps. The cost to you is the cost of the diskette and postage. No other 
compensation can or will be accepted--please do not send money. We have 
included a configuration file facility so that you can tailor many parameters 
to your specific system. Of course, you may also obtain ARES/Data from anyone 
who already has a copy, and you're encouraged to give the program to other 
interested radio amateurs. 
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ROSE X.25 Network Growth 
Thomas A. Moulton, W2V Y 
Radio Amateur Telecommunications Society 
Introduction 


The ROSE X.25 Packet Switch has been a developing project over many years. 
There have been many groups that have aided in the testing of the software. Without 
the efforts of these groups the switch would not have been as successful as is now is. 


Last Year 


A year ago there were a couple of switches operational in NJ and maybe a 
dozen of other switches running throughout the US and Canada. There were a few 
low level problems that would cause the software to be unreliable. The general reports 
were "When it works it works good, but it crashes”. Overall the switches have been 
very reliable since the beginning of the year. 


The Bug 


At the end of the 1988 a bug was found that dealt with an interaction between 
the I/O routines and the C compiler. This was "THE BUG" that was causing a high 
majority of the crashes. Once THE BUG was repaired the development was able to 
proceed forward once again. 


Current Networks 


There are now large scale networks in operation in NJ, KY, Australia and 
Central America. (See attached maps) There are other networks in PA, AZ, CA, AK, 
FL, IN, OH. 


The performance of a ROSE X.25 Network is better than other schemes. The 
timing parameters are set up to provide fair sharing of user access channels. 


The BBS operators notice higher reliability for longer connect paths as well as 
higher throughput. They also can access any system within the network with a single 
command, which makes the connect scripts simpler. This also eliminates the need to 
make changes in the scripts when there are changes internal to the network. 


The Network System Manager has greater freedom to make changes within the 
network. The only time they need to notify users and BBS operators of changes Is 
when network end points are being removed. Expansion or addition of backbones and 
other internal changes are transparent to the users as long as the connectivity 1s 
maintained. 


Conclusion 
These are just the major advantages of using a ROSE X.25 Network, there are 
many other subtle changes that combined with these make a ROSE X.25 Network the 


best solution for Amateur Networking. 


Try it, You'll Like it! 


MD 
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The ROSE X.25 Packet Switch 
Thomas A. Moulton, W2VY 
Radio Amateur Telecommunications Society 
Abstract 


The ROSE X.25 Packet Switch is the product is many years of effort and 
experience in the data communications market. The design goal was to provide a state 
of the art networking device that could clearly be used as a building block in the 
creation of a global amateur data network. The switch is a very reliable and efficient 
alternative for amateur packet radio networking. There are currently at least fifty (50) 
switches in operation throughout the world. It is felt by many groups that it is the best 
solution for amateur packet networking. 


Introduction 


The ROSE X.25 Packet Switch is an advanced replacement for the common 
digipeater or other node switching EPROM. The ROSE Switch represents the state of 
the art in packet switching technology using international standard protocols. It is 
based on the CCITT X.25 Network Layer, and the ARRL AX.25 Link Layer 
Protocols. 


The ROSE X.25 Packet Switch is the best solution for Amateur Packet Radio 
Networking. A ROSE Switch can be accessed by standard AX.25 TNCs supporting the 
AX.25 Link Layer protocol. The AX.25 Link Layer protocol is also used on paths 
between backbone switches. The X.25 Network Layer protocol is used by the switches 
to transfer the users’ data through the network. See the ROSE X.25 Packet Switch 
Users Manual for a complete list of features. 


Addressing 


The ROSE X.25 Packet Switch supports the global addressing plan adopted by 
CCITT and ISO. This plan includes a country code and a national network number. 


The ROSE Switch follows the numbering plan in use in the national X.25 packet 


switching network, most packet networks follow the telephone numbering plan used 
in that country. North America uses the telephone Area Code and Exchange. 


This system will allow a user to request a connection with another station 
without any concern given to the exact path the data will follow. This is in sharp 
contrast to the explicitly specified approach used by digipeaters. The motivation for 
this is that the general user population doesn’t care to, or have time to, keep abreast of 
the networking changes over time. The routing is under your complete control, so 
users can’t clog the network with retries on obsolete RF paths. Users only need to 
know the Network Address of the destination, which is like a telephone number. 


The ROSE Switch may be configured with several paths to remote Area Codes 
or countries. Each of the specified links will be tried in the order they were specified 
to find an operational route. This is an improvement on several existing amateur 


systems which can only provide implicit destination routing to switches known by the 
source switch. 


The telephone exchanges are allocated based on the population density of each 
area. A single ROSE X.25 Switch can provide RF coverage of many different 
exchanges. A full list of exchanges that the switch should handle as its own can be 
specified. 


The addressing also needs to support routing to different countries, the X.121 
standard handles this with a prefix country code. In data networks the country code is 
called the Data Network Identification Code (DNIC), the ROSE Switch supports up to 
8 different DNICS, and will be expanded as the networks grow. The user can specify 
the DNIC in the TNC connect command by adding an extra four digit digipeater field 
between the switch callsign and the network address, for example to connect to 
VE7APU in Canada you could enter the following command: 


C VE7APU V N2DSY-3,3020,617385 


The ROSE Switch would see the four digit group and the fact that another 
digit field followed it and merge the numbers, resulting in an address of 3020617385. 


If you get a call from a station that is in a different DNIC than the ROSE 
Switch you use, it will insert the correct DNIC in the digipeater field preceding the 
network address in the connect request. This insures that you know how to reach the 
user at a later date, as well as providing identification of international contacts which 
sometimes require special considerations by the users in the contact. 


Routing 


The ROSE X.25 Packet Switch supports a very flexible static routing scheme. 
The routing is static in that the the routing tables are not automatically updated in 
any way. The normal method of having automatically updated tables is through the 
use of various broadcasts for routing updates, ROSE does not do this. Instead the 
system manager should configure the switch with all the reasonable paths for a given 
address. This avoids the problem of short band openings that provide routing 
information but no useful data transfer. 


When attempting to route a call request the switch will obtain the alternative 
list for the address specified from the routing table. The list contains a sequence of 
which local switches can handle the call in order of the preference of the path. 


The most preferred switch that is not listed as "Out of Order" will be sent the 
call request. If that switch responds with a network level error, such as "No Path" or 
“Out of Order" the next path in the alternative list will be tried. If it runs out of 
alternatives the call will be cleared with a cause of “Out of Order". 


A switch will mark a local switch as "Out of Order" if it can not establish 
network level communications with the switch. The switch will be considered as "Out 
of Order" for a configurable period of time. 


A routing loop can occur when a switch receives a call request that it has 
already routed to another switch. This is detected by the switch by examining the 
following information from the call request packet; Source Network Address, Source 
Call Sign, Destination Call Sign and a random number, 
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The random number is comprised of an 8 bit call sequence number and an 8 bit 
random number. The call sequence number is incremented for each new call request a 
switch handles. If a loop is detected the second call request is cleared with a network 
level error and the preceding switch will then try the next alternative. 


Network Definition 


Designing local network topology can be an art in itself. The following is a 
good template that can be used to determine a first best guess as to how the various 
paths should be used. Once you have a network operational you should try various 
paths to optimize the traffic flow. In many cases gut feelings should be tried as there 
are things we all know about RF paths that I haven’t been able to put into words. 


In order to define a network of ROSE X.25 Packet Switches, perform the 
following steps: 


1) Draw a network layout consisting of switches and the usable RF paths 
between each adjacent switch. 


2) Assign each switch a callsign and address consisting of the telephone Area 
Code and Exchange of the location of the switch. 


3) Prioritize the reliability of each switch’s outbound links. Preferred paths 
should have many of the following characteristics; Solid paths, low volume paths; high 
speed channels; and low contention. In general the number of emitters on a given 
frequency should kept low. Hidden transmitters should be eliminated. All the emitters 
should hear each other well enough to cause the carrier to be detected by the modem. 
The shortest path between two points is the path with the most available band width, 
not the shortest distance! 


4) For each link list the switches within your network that can be reached. If a 
switch shows up more than once decide the order that they should be used, usually 
"shortest" to "longest". Inter-switch traffic on a user channel should be avoided. 


5) Next decide the best path for traffic from switches outside your control 
should follow. These can be thought of general directions, such as North, South, etc. 
Usually the inter-LAN boundary is obvious, all you have to do is decide what route 
through your switches you want this foreign traffic to follow. This route is a good 
candidate for a backbone channel on a different band. 


When each of these items is defined, you will have completed a basic network 
design. The method is minimal, but it will assist you in understanding the workings of 
the network when you start the deployment phase. It will also be helpful when trying 
to debug network problems. 


Network Configuration 


In a ROSE X.25 Network each switch has a description of what the network 
looks like from it’s point of view. This consists of a list of switches that it talks to 
directly and routing information. The routing information describes what network 
addresses each of the switches in the list can handle. When a connect request is 
received by a switch it must be able to decide where the request should be sent next. 
Connection requests can be from either a local user or from another switch. 


The configuration of a switch is stored in a file that contains four sections. 
These are: 


1) Default Parameters 

2) Information about the switch being configured 

3) A list of switches local to the switch being configured 
4) Routing information, who should handle what addresses 
Default Parameters 


There are four switch parameters that can be defaulted, the form of the default 
command is: 


DEFAULT par Value 
Where the "par" is one of the following and the value is as described. 


L3W 1.7 


This configures the Level 3 Packet Window, much like MAXFRAME for TNC 


Links. As noted valid values are 1 through 7. 
TimeOut 0.65535 


When a network Link is not operational due to a radio failure or interference 


a timer is started to keep the switch from continuously trying to bring up the link. 


This is done to reduce the time required to route around a malfunctioning switch or 
path. The suggested value is 900 seconds (15 Minutes), but other values can be used 
from 0 to 65535 seconds (18 Hours). A realistic minimum value is 3-5 minutes. A lower 
value could cause the call router to try a bad link more than once with the same call 
request. 


MaxVC 0.254 


This parameter sets the number of VCs, or simultaneous connections, that will 
be allowed on a Link to another switch. The recommended value for this is 20. A 
special case occurs when this statement appears in a USER block statement. 


Port 0.4 


This defines which serial port on the switch the Node or User is said to be 
listening. On a TNC-2 the radio is Port 0 and the RS-232 connector is Port 1. 


The recommended values for these defaults are: 


DEFAULT PORT 0 
DEFAULT TIMEOUT 900 
DEFAULT L3W 4 
DEFAULT MAXVC 20 
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Include 


This default parameter defines a directory that the configuration program will 
check for include files (*<). This directory is only checked if the included file is not 
found in the current directory. 


DEFAULT Include C\ROSENET\ 
Information about the switch being configured 


The first thing that must be done is a declaration of what country this switch 
is in. This is done with the DNIC command, which has the form: 


THIS DNIC 3100 United States of America 


The THIS command is used on the beginning of a statement to identify that 
the rest of the line is for the switch that is being configured. 


The 3100 is the country code for the USA within the data networks. A 
complete list of DNICs can be found in the ROSE X.25 Packet Switch Users Manual. 


Once this is done you can define the internal information about the switch 
being configured. Again we use the THIS prefix to identify we are talking about the 
switch being configured. 


THIS NODE Clifton 


The NODE statement is a Block Statement that is terminated with an END 
Statement. 


Note: The location name, Clifton in this case, is only used within the 
configuration file, not on the air. 


Each switch must have a Network Address, this is what is used to reference 
the switch as the destination of a Call Request from anywhere in the network. 


ADDRESS 201478 
The address can be from 1 to 6 digits long and must follow the national 
numbering plan in use for the X.25 network. In the United States of America this 


must be the Area Code and local Exchange of the location of the switch. 


In order for users and other switches to establish Links to this switch it must 
have an Amateur callsign. 


CALL W2VY-3 


CALL is short for CALLSIGN in this case. The EPROM default for the 
callsign is ROSE-3. 
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Each switch also has a callsign that can be used for digipeating, this may be 
the same as the CALL. The default digipeat callsign is ROSE-2. If the CALL and 
DIGI are the same they both still need to be specified. 


DIGI W2VY-2 


If a switch has a RF coverage that crosses more than one telephone exchange 
then these extra exchanges can be specified in the COVERAGE statement. This is a 
Block Statement and is terminated with an END. This is an example of a nested block 
statement, we are still in the "This Node Clifton" Block. 


COVERAGE 

201472 201473 201777 201779 201470 201478 
201778 201772 
END 


Each of the Network Addresses listed above will be treated as if they were the 
switch Network Address, 201478 in this case. 


When a Call Request is received that has this switch as the destination, address 
201478 or one in the Coverage list, the switch will attempt to establish a Link with the 
specified user. If the switch is running on multi-port hardware, such as a PacComm 
DR-200 there are times when you need to specify which Port the users are resident on. 
The USERPORT statement specifies which Port should be used to establish Links to 
users. On a TNC-2 the Radio port is port 0. On a PacComm DR-100 the radio port is 
port 1. 


USERPORT 0 


A user can connect to the switch and get information about how to use the 
network, or other information of general interest. This is specified in a TEXT block, 
which is ended with "$EOF". A blank line is inserted by having a “$" on a line by itself. 


TEXT 

$ 

While Disconnected From THIS X.25 Switch issue a command like: 

$ 

C CALLSIGN-SSID V W2V Y-3,201256 

$ 

Switches Available for User Access are: 
Address Callsign Location User Port Freq 

201256 W2V Y-3 Montclair 221.11 Mhz 
201744 N2DSY-3 LittleFalls,NJ 145.07 Mhz 
609426 KA2VLP-3 Hightstown,NJ 145.07 Mhz 
609261 WA3YRI-3 MtHolly,NJ 145.07 Mhz 
212456 KD6TH-6 Manhattan,N Y 145.07 Mhz 
609530 N2EVW-9 Ewing,NJ 22L01 Mhz 
609883 N2EVW-8 Trenton.NJ 221.11 Mhz 
201663 N2ELC-3 Lake Hopatcong,NJ 145.09 Mhz 

$ 


Possible connect paths available to access BBS User ports. 

C KBIBD-4 V W2V Y-3,609426 : C WA2VXT-4 v W2VY-3,609426 
C KD6TH-4 V W2VY-3,201744 : C N2ELC-4 v W2VY-3,201663 

$ 
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Connect Paths Available to KA-Nodes or TheNET Facilities: 

C WB2DRD-3 V W2V Y-3,609426 : C WB2MNF-3 V W2V Y-3,609530 

$ 

When connecting to TheNet Nodes act as if you have connected direct to it. Type C 
NODENAME, after you have connected to either of the TheNet nodes listed above, 
to connect to the next desired node. Type NODES to get a node list after your 
connect or type Info to get information about the particular TheNet node you are 
connected to. Example: To connect to ELK TheNet node use the following sequence: 
C WB2DRD-3 V W2V Y-3,609530 

C ELK 

$ 

You will shortly be Disconnected from this switch. If you are currently connected via 
either TheNET or KA-Node RECONNECT to THAT node and then issue a connect 
as shown above. Note: It has come to our attention that those systems using old TNC] 
code will not accept all digit fields, substitute o for 0 and 1 for 1 in the all digit field 
and you will be successful. Disconnect codes can be found on the KBIBD-4 PBBS, 
filename is DISCO.COD. Please address questions to KBIBD@KBIBD or 
W2VY@KD6TH. This switch brought to you courtesy of RATS. Enjoy 73 Tom 
W2VY 

$EOF 


This connect TEXT can be up to 2048 bytes long. 


To terminate the definition of the Clifton Node the END statement is used, 
completing the block statement. 


END 
Local Switches 


The next section describes the switches that this switch communicates with 
directly. 


NODE Manhattan 
ADDRESS 212456 
PATH KD6TH-3 
END 


This defines a local switch that has the callsign KD6TH-3 and network address 
212456 and is located in Manhattan. Based on the current defaults it is also on PORT 0 
with a link timeout of 15 Minutes and can support up to 20 calls. Each call will 
operate with a level 3 packet window of 4. 


For the purposes of this description we will also define three other local 
switches. 


NODE LittleFalls 
ADDRESS 201744 
PATH N2DSY-3 
END 


NODE Clifton2 
ADDRESS 201779 
PATH W2VY-9 
PORT 1 

END 


NODE Montclair 

ADDRESS 201256 

PATH W2VY-12 Via KBIBD-2 
END 


Each of these are pretty standard with the following exceptions. Clifton2 is on 
PORT 1, which would be the asynchronous port if we are running on a TNC-2 and 
that port could be connected to either a modem and radio or a back to back cable to 
another TNC. Montclair has a digipeater specified, the path to a switch can include up 
to ONE digipeater. 


If you have a special device that is not on the USERPORT channel you can 
configure it in the switch as a USER. If this USER is not an X.25 Pad (ie it’s a TNC 
or TheNet/NetROM) you must specify MAXVC 0. 


USER KD6THbbs 
PATH KD6TH-4 
PORT 1 

MAXVC 0 

END 


If a call came in for KD6TH-4 with a switch address of 201478 the switch 
would attempt to establish the link on Port 1, as was specified. This can be done for 
any AX25L2 device, such as a TheNet or NetROM, as well as a BBS. Users are not 
encouraged to be placed on the backbone. If using a TNC-2 you would just specify the 
address of the switch that had the radio port on the backbone. This feature is used 
mostly when the switch is running a PacComm DR-200, or other multi-port 
synchronous device. 


Routing Information 


The route statements specify what local switches should be given calls for 
which network addresses. This is usually divided into two parts, first specifying the 
routing needed for the switches within the local network (the switches you control) 
and the second specifying the routing for out of area network addresses. 


The general form of the ROUTE statement is: 


ROUTE TO NODES node-list 
CALLS FOR 
network-address-list 

END 


Where "node-list” is a sequence of switches; and "network-address-list" is a list 
of Network Addresses. If a Call Request is received for one of the addresses in the list 
the switch will use this routing information to pass the Call to the next switch. The 
switches are tried in the order they are listed, so the best route should be listed first, 
worse last. It has been done this way because by and large there are a limited number 
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of ways to get from this switch to a remote region. From the Clifton switch I can 
route calls for New England to Manhattan or Little Falls, so the following statement 
would set up the required routing entries. 


Route to Nodes Manhattan LittleFalls 
Calls for 

207 802 617 508 413 203 401 

518 607 212 718 716 516 914 315 

end 


I also included the Area Codes for New York. 


We also need to include the routes for the local switches. The routing 
information here should include the address of each switch as well as the addresses in 
it’s coverage. 


Route to Node Manhattan 
Calls for 

212456 

end 


Route to Node LittleFalls 
Calls for 

201744 

end 


As well as addresses to the south and west: 


Route to Node LittleFalls 
Calls for 

609 215 717 202 

end 


There are files included with the distribution diskette that have the Area 
Codes for the entire USA, broken down by state and call district, see NPA.ARC. 
These files can be placed in a separate directory and included in the configuration 
with the *< command. 


Now that we have defined the configuration of a switch we need to create, and 
save to disk, the file that the switch can understand. The WRITE statement is used to 
create this file. 


WRITE w2vy-3.tbl 


The file naming conventions that we use here in NJ are the statements that 
were used in the example are stored in a file with the name CallSign.CNF and the 
output is stored in the file CallSign.TBL. ("\CNF" Configuration; ".TBL" Table) 


The last statement of each .CNF file should be a QUIT to tell the 
configuration program to terminate and return to the operating system. 


Additional Configuration Commands 


If you are having problems figuring out an error, it can be helpful to see the 
commands that the program is reading. You can cause the configuration program to 
print each statement as it reads it in by including a VERIFY statement. 


VERIFY 
.. statements causing problems... 
NOVERIFY 


The NOVERIFY statement turns this feature off, there can be any number of 
VERIFY/NOVERIFY statements in a configuration file. 


Special Characters to the Configuration Program 


Any line in the configuration file (.CNF) that starts with an asterisk (*) is 
treated as a comment, which can be useful to indicate extra information about a 
switch, such as equipment at the location, access rules, failure history, etc. 


There is one exception, if a line starts with "<" the configuration program will 
treat the text on the rest of the line as a file name. The program will expect the file to 
be in the current directory or the directory specified in the Default Include statement. 
The contents of the file will be read in as if it had been in the main file. If the file is 
not found an error message will be printed. 


The file that is being read in can not have another "*<" in it, this may be 
revised in later versions of the configuration program. 


Route to Nodes Manhattan LittleFalls 
Calls for 

*<wLnpa 

*<ny.npa 

end 


This would be the same as the previous example of routing the calls for New 
England and New York, using the supplied files in NPA.ARC. 


ROSE X.25 Packet Switch Applications 


A Switch Application is a special type of network destination, like a BBS is a 
special callsign that you connect to. Once connected to it you can issue commands and 
get replies. The following sections describe the existing applications and list any 
commands and example replies. 


To connect to a switch application you would follow the same procedure that 
you would to connect to a user, but instead of entering a user’s callsign you enter the 
name of the application. If your local switch is W2V Y-3 and you want to interact with 
the MEMSIZ application at network address 201478, you would issue the following 
connect command: 


C MEMSIZ Via W2V Y-3,201478 


This is a standard ROSE X.25 Packet Switch connect request. The local switch 
would route the Call Request to the switch with the network address 201478 When a 
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switch receives a Call Request it first checks to see if the destination "callsign" 
matches any of the currently loaded applications. If the application is found the 
switch would set up connection with the application. If the application was not loaded 
it would assume that it was a local user and attempt a connect on the userport. 


Once connected to the MEMSIZ application you would get the ROSE banner: 
ROSE X.25 Switch Version 890820 by Thomas A. Moulton, W2VY 


This would indicate that the connection is complete and you could start 
interacting with that switch. 


The CONFIG and LOADER applications accept commands that are in an 
obscure Intel Hex like format, this will be replaced with plain language commands in 
the future. 


LOADER Application 


The LOADER application is resident in the EPROM, this means it is always 
present. As you may be able to guess from the name, it is used to load other programs 
into the switch. This will allow you to chose which switches will have what functions. 


The files with the filename extension "LOD" are files that can be sent to this 
application, which will cause the specific application to be loaded into memory. The 
file "CONFIG.LOD" when sent (ASCII/TEXT upload) to LOADER would cause the 
CONFIG application to be loaded into memory. 


When loading a .LOD file you should get three "OK’"’s back, the only other 
message you could get would be "Error n" where N is a numeric value indicating what 
type of error occurred, the following table lists the possible error numbers. 


Error # _ Meaning 

01 Invalid command 

02 Invalid Object 

03 Unable to allocate memory for program 

04 Incorrect checksum 

09 Length mismatch of code segment in .LOD file 
OC Can’t delete non-existent application 

OD Need to load code segment before relocation info 
OE To many applications loaded, max is 15 

OF Unsupported object 

10 Unsupported command 


LOADER also supports two other commands: 
List Applications "0000000000" 


This command will cause the switch to list all the applications that are 
currently loaded into the memory. When the switch is first powered on the list will 
look like this: 


Entry #0 LOADER - Application Boot interface 
OK 
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If the switch has all the applications loaded into memory then the list might 
look like this: 


Entry #0 LOADER - Application Boot interface 

Entry #1 CONFIG - ROSE X.25 Packet Switch Configuration Interf.. 
Entry #2 USERS - ROSE Switch User List Display, Version 1.0 
Entry #3 MEMSIZ - ROSE Memory Utilization Display 

OK 


The entry # is just the position in the list that the application is listed, this 
number is only important when you are using the Delete command. 


Delete Application ":02ee000000" 


This command will remove an application from memory, thus freeing the 
memory to be used for other things such as data buffers or additional connections. 
The "ee" is the entry number the application 1s in the list. 


Lets say you want to delete the CONFIG application from a switch, first you 
would connect to the LOADER and then list the applications: 


0000000000 

Entry #0 LOADER - Application Boot interface 

Entry #1 CONFIG - ROSE X.25 Packet Switch Configuration Interf.. 
Entry #2 USERS - ROSE Switch User List Display, Version 10 
Entry #3 MEMSIZ - ROSE Memory Utilization Display 

OK 


Notice that the CONFIG application is in entry #1 this time, you would enter 
the following command, replacing the "ee" with "01". 


0201000000 
OK 

You could then verify that it was done by entering the list command again. 
The "OK" does tell you that it was in fact done, but we'll check anyway, you don’t 
have to check. 


Entry #0 LOADER - Application Boot interface 

Entry #1 USERS - ROSE Switch User List Display, Version 10 
Entry #2 MEMSIZ - ROSE Memory Utilization Display 

OK 


Note that all other applications moved up in the application list. 

When you are done interacting with the LOADER you just disconnect. 
USERS Application 

The USERS application is used to list the users that are currently using the 
switch; connected to a local user/bbs; passing through to another switch; or interacting 


with an application that has been loaded. Once you are connected just hit return to 
view the current status of the connections. 
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ROSE X.25 Switch Version 890820 by Thomas A. Moulton, W2VY 
[You Press Return] 


User List for N2DSY-3 3100201744 


Memory Size is 29kb 
Memory Used is 12kb 


W2VY AX25L2 User Linked to USERS  @ 3100201744 

W2VY AX25L2 User Linked to LOADER  @ 3100201744 
W2VY-3 X.25 Trunk (R1) with the following connections: 
KD6TH4 @ 3100201256 (20 P4 D1)<-~- KBIBD-5 @ 3100609443 
WB2JQR-3 X.25 Trunk (R1) with the following connections: 
KBIBD-5 @ 3100609443 (20 P4 Dl) -> KD6TH-4 @ 3100201256 


There are no calls Pending. 


The Following X.25 Trunks are listed as Out of Order: 
<None> - All Links Operational 


The first line identifies the callsign and address of the switch that the display 
is for. This is followed by the memory usage of that switch. 


The second section shows all active connections. The first connection is my 
station connected to the USERS application (its how I generated the above display). 
The second connection is my station connected to the LOADER application. Note 
that a connection that is listed as "AX25L2 User" is a user directly connected to that 
switch. 


Now things start to get interesting, W2VY-3 is another ROSE X.25 Packet 
Switch and it has one VC. The VC is between KBIBD-5 at address 609443 and 
KD6TH-4 at 201256, these are two BBSs doing forwarding. 


In this case neither BBS is local so the call also shows up on a second X.25 
Trunk. The arrow indicates the direction that the connect request went in, ie. KB1BD- 
5 called KD6TH-4. 


Note that this connection shows up twice, once to enter the switch and once to 
leave. If a user was using the switching function to connect to a station on the same 
switch there would be two entries listed as AX25L2 Users. 


A pending call is a connect request that came in while the trunk, or link, to the 
required switch was not ready. A Call is left in the pending state while the Switch 
attempts to bring the link into the ready state (R1). 


If a link to a switch is not operational then it is marked as being Out of Order 
for a specified time. 


MEMSIZ Application 


The MEMSIZ application was just a test program for me to verify correct 
operation of the loader. It turns out that it can be useful to monitor the amount of 
memory that is being used by the switch from time to time. This information is also 
included in the USERS application display. The values are listed in hexadecimal. 


Memory Size is: 7578 
Memory Used is: 4155 


CONFIG Application 


The CONFIG application is not designed to be used directly by the switch 
manager. It is just an interface that processes the file created by the Network 
Configuration Program (CONFIGUR.EXE). This section will describe the interface 
for completeness, and there may be times when you might want to check some of the 
settings. All replies are in hexadecimal and are not easy to interpret. As with the 
LOADER interface every command will generate either an "OK" or "Error n" when 
the processing of the command is complete, the meaning of each of the errors are as 
follows: 


Error # Meaning 

01 Invalid command 

02 Invalid Object specified 
03 No working memory! 
04 Bad checksum! 

05 Unsupported Command 
06 Odd number of data bytes for type 
07 Item is Read-Only 

For OD object only: 

01 No working memory 
02 Invalid DNIC 


The CONFIG application allows modification of the following data objects 
within the switch: 


“The TEXT that a user can access if they connect directly to the switch and hit 
return. 


* The Call sign and digipeater call sign of the switch. 

* The call signs of any switches this switch communicates with. 

* The call sign and port number of any configured Users 

“ Network parameters such as Maximum number of VC's, Level 3 Window. 


* The TIMEOUT value for a failed network link, ie one that is marked "Out of 
Order". 


* Port that the level 2 users are found on. 


* Network address of this switch. 
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* AX.25 level 2 parameters for user connections. (Maxframe, Paclen, Resptime, Frack, 
Retry) 


* AX.25 level 2 parameters for X.25 Network links. 
* The routing tables remote call requests. 
Programming the EPROM 


If you have access to an EPROM programmer you can use one of the files 
supplied, either the Intel HEX file ROSEZSW.HEX, or the binary image 
ROSEZSW.BIN. If you do not have access to a programmer you can obtain a pre- 
programmed EPROM from the author. 


NOTE: The SAME EPROM will function in TNC-2/Clones and the PacComm DR- 
100/200, the initialization code checks it all out and sets up the system. A test switch 
will work fine with 16K, but it is recommended that a fully functional network switch 
is installed with 32K. 


Permanent Configuration of the Switch 


The distribution includes a "MAP" file that contains the EPROM address of all 
entry points and important variables. Using this information you can modify the 
default parameters in the EPROM. The format of the data falls into four forms. A 
byte, a word, a callsign and a network address. 


A byte is simply a single location in the EPROM which can hold a value from 
00 to FF (that is 0 to 255 decimal). 


A word is a two byte value with the low order byte of the word stored at the 
lower EPROM address. A word can contain a value from 0000 to FFFF (that is 0 to 
65535 decimal). Since it is stored low byte at low address the value 01 00 is 1 decimal, 
and 00 01 is 256 decimal, or 0100 hexadecimal. 


A callsign is stored in AX.25 format, the same way it appears in packets sent 
over the air. Each callsign is a six byte shifted ASCII callsign followed by a single 
byte SSID, for example in the EPROM the callsign ROSE-3 would have the following 
format: 


A4 9E A6 8A 40 40 06 


A network address is stored in CCITT X.25 address format, which is a length 
byte followed by a BCD representation of the address, for example the address 
3100201779 would have the following tormat: 


OA 31 00 20 17 79 


Note that the length (OA, 10 decimal) is the number of BCD digits, ie "31" is two 
digits. 


If you are outside the USA the numbering plan may use something other than 
six digit codes, if the length is ODD then just pad the last byte with an extra 0, but 
leave the length ODD. I know Australia uses a variable length numbering plan, the 
format for node address 50502 (which is the region code for Sydney) would be: 


05 S50 50 20 
Note that the length is 5 (50502) and the last digit is ignored and should be 0. 


The following "MAP" file labels identify the location of the following 
EPROM defaults: 


“myaddr" - Network address of this switch 

"mycall” - Callsign of this switch 

"mydigi” - Callsign this switch recognized for digipeating 
"defdnic" - Default local DNIC, EPROM has USA: 04 31 00 


Power ON Indications for TNC-2 
The ROSE X.25 Packet Switch has a two phase initialization sequence. 


In the first phase you should see the PWR, CON and STA lights come on for TWO 
(2) seconds while the Switch tests RAM and verifies the battery backed up RAM. 


The second phase the CON and STA LEDs are used to indicate what was going on 
when the switch was powered off. This indication is displayed for THREE (3) seconds 
(they both normally stay on). If they both go out, then the switch was processing data 
when the power was removed. When powering a unit as a ROSE Switch for the first 
time, this display is meaningless. 


At this point the CON and STA lights should alternately turn on and off once a 
second, this indicates that the switch is operating correctly. 


Configuring a ROSE X.25 Packet Switch 


The following example shows how to configure a switch from anywhere 
within the local ROSE X.25 Network. 


emd:c_w2vy-3 
*™* CONNECTED to W2VY-3 


{Hit Return] 
ROSE X.25 Switch Version 890820 by Thomas A. Moulton, W2VY 
™** DISCONNECTED 


Since the text is not loaded, there must have been a power failure at the site, 
and therefore the CONFIG application needs to be reloaded. 


cmd:c_ loader v_ w2vy-3,609426 

*** CONNECTED to LOADER VIA W2VY-3,609426 

ROSE X.25 Switch Version 890820 by Thomas A. Moulton, W2VY 
Entry #0 LOADER - Application Boot interface 

OK 
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The CONFIG application is NOT loaded, so now you would send the file 
CONFIG.LOD, it is an ASCII TEXT file. 


You then get the 3 OK’s and disconnect. 


cmd:d 
cmd:*** DISCONNECTED 


cmd:c config v w2vy-3,609426 
™“* CONNECTED to CONFIG VIA W2VY-3,609426 
ROSE X.25 Switch Version 890820 by Thomas A. Moulton, W2VY 


Now send the .TBL file and receive 11 OK’s, when done disconnect. 


cmd:d 
cmd:*** DISCONNECTED 
cmd: 


The switch is now reconfigured. 


In an operational network any switch can be loaded from any point within the 
network. You just need to issue a connect command to your TNC that had the callsign 
of the local switch, followed by the network address of the switch you wish to interact 
with. 


When accessing a completely unconfigured switch remember the default 
callsign is ROSE-3 and the default address is 000000. This should only happen the first 
time you bring up a switch. If you notice that the switch fails to remember it’s callsign 
after the power has been removed for a short time, that may indicate that the battery 
needs replacing. Lithium batteries are usually good for 3 Years - TAPR TNC-2’s 
should be needing new batteries soon! 


Asynchronous Communications 


The ROSE X.25 Packet Switch supports the asynchronous port of a TNC-2 or 
Clone as just another radio port. The goal is to allow connection to any standard RS- 
232 device, such as a modem. The RS-232 signals operate in a normal fashion which 
allows connection to conventional land line modem, multiplexers or any other 
communications equipment that is available to provide backbone linking. 


The immediate application is connection of a Bell 202 modem and a radio to 
provide a local backbone for a given area. This type of set up requires half as many 
TNC’! 


Two or more switches may also be tied together on the RS-232 ports to provide 
multiple synchronous ports from a single site. 


Asynchronous pin definitions: 


All connections are to J1 (DB 25) 


Pin # Direction/EIA Pin Designation/Usage 
1 [5] NA/Frame Ground 
2 [3] In/TXD/Data On 


3 [2] Out/RXD/Data Out 


5 [8] Out/CTS/Request To Send (Async PTT) 
7 NA/Ground 

10 Out/LO/Pull Down signal 

20 In/DTR/If LO wired Back to Back 

- ./If not LO used as Radio Port 

23 [9] In/SEL/Carrier Detect 


Note: Pin numbers in brackets are for PacComm Tiny-2 and Micropower. For Tiny 
and Micropower in Back-To-Back configuration also need to add jumper from U15 
(MAX231) Pin 3 to U15 Pin 4. 


Differences between ROSE and Net/ROM Back-to-Back Cable 


The asynchronous port of a Net/ROM is not standard RS-232 signaling. In 
order to be able to use the diode matrix Software 2000 inverted the meaning of the 
Request to Send (RTS) signal. 


Asynchronous Radio Port Cable 
Radio Port Cable Needs: 
CAPS mean TNC, lower means Modem DB25 


GND PIN 1- gnd pin 1 

TXD PIN 2-rxd pin 3 

RXD PIN 3- txd pin 2 

CTS PIN 5- rts pin 4 (Radio keying circuit/PTT) 
DSR PIN 6- dtr pin 20 (depending on Modem) 

GND PIN 7- gnd pin 7 (Optional) 

SEL PIN 23 - ded pin 8 (Tie Modem DCD to sio dedb) 


Wiring two TNCs for Back-to-Back Operation 
CAPS mean this TNC, lower means the other TNC 


GND PIN 1— gnd pinl 

TXD PIN 2 ——rxd pin 3 

RXD PIN 3 —— txd pin 2 

CTS PIN 5 --——- sel pin 23 

GND PIN 7 —— gnd pin 7 (Optional) 
DTR PIN 20 —— LO PIN 10 

SEL PIN 23 -—— cts pin 5 


Wiring many TNCs for Back-to-Back Operation 
There have been a number of methods attempted for connecting a collection 


of switches back to back. The most reliable is a board that contains RS-232 drivers and 
receivers with some simple TTL logic. A schematic for a four port board is available 
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from the author. An eight port board can also be done by changing the 4 input AND 
gate (74HC21) to an 8 input device. 


The future developments planned 


There a number of new features planned for the coming year, these include 
additional loadable applications and some changes to the basic switch kernel 
(EPROM). 


The items with the highest priority are moving the routing table into battery 
backed up RAM and password protection of the LOADER application. Additional 
information to aid in evaluation of network performance needs to be collected, items 
such as: Frame and Packet level statistics, call detail records and automated error 
reporting. The call detail records will contain information such as: call duration, bytes 
sent, bytes received, source and destination and the clearing cause. 


The targeted applications will primarily be for additional user and 
management features. These include: Heard Logs, Monitoring remote ports, Reliable 
Information Broadcast, Round Tables, controlled Beacons such as CQ and other tools 
for message forwarding. Any suggestions are welcome! 


The ROSE X.25 Packet Switch will soon be operational in a wider range of 
hardware models. At that point there will be a program that will allow linking of a 
Switch for a specific TNC, as part of this linking process applications can be specified 
for inclusion in the EPROM. This will allow elimination of needless features for the 
specific switch. A backbone switch does not need the Level 2 User access interface or 
the information text connect message. 


Conclusion 


The ROSE X.25 Packet Switch is the most advanced packet switch for amateur 
packet networking. The growing collection of features and use of state of the art 
protocols enable it to play a key role in the growing Global Amateur Packet Network. 


This is just the first tool for the RATS Open System Environment. Other 
projects have been identified and will be supported by or supportive of the ROSE 
X.25 Packet Switch. The Radio Amateur Telecommunications Society is committed to 
development of state of the art networking for the amateur service. 


Appendix 1 - Network Configuration Example 
THIS DNIC 3100 United States of America 


THIS NODE Clifton 

ADDRESS 201478 

CALL W2VY-3 

DIGI W2VY-2 

COVERAGE 

201472 201473 201777 201779 201470 201478 
201778 201772 

END 

USERPORT 0 

TEXT 

$ 

While Disconnected From THIS X.25 Switch issue a command like: 


$ 
C CALLSIGN-SSID V W2V Y-3,201256 


$ 
Switches Available for User Access are: 
Address Callsign Location User Port Freq 
201256 W2VY-3 Montclair 221.11 Mhz 
201744 N2DSY-3 _LittleFalls,NJ 145.07 Mhz 
609426 KA2VLP-3 Hightstown,NJ 145.07 Mhz 
609261 WA3YRI-3  MtHolly,NJ 145.07 Mhz 
212456 KD6TH-6 Manhattan,NY 145.07 Mhz 
609530 N2EVW-9_ Ewing,NJ 221.01 Mhz 
609883 N2EVW-8  Trenton,NJ 221.11 Mhz 
201663 N2ELC-3 Lake Hopatcong,NJ 145.09 Mhz 
$ 
Possible connect paths available to access BBS User ports. 
C KBIBD-4 V W2V Y-3,609426 C WA2VXT-4 v W2V Y-3,609426 
C KD6TH-4 V W2VY-3,201744 C N2ELC-4 v W2V Y-3,201663 
$ 
Connect Paths Available to KA-Nodes or NETROM Facilities: 
C WB2DRD-3 V W2V Y-3,609426 C WB2MNF-3 V W2V Y-3,609530 
$ 


When connecting to TheNet Nodes act as if you have connected direct to it. Type C 
NODENAME, after you have connected to either of the TheNet nodes listed above, 
to connect to the next desired node. Type NODES to get a node list after your 
connect or type Info to get information about the particular TheNet node you are 
connected to. Example: To connect to ELK TheNet node use the following sequence: 
C WB2DRD-3 V W2V Y-3,609530 

C ELK 

$ 

You will shortly be Disconnected from this switch. If you are currently connected via 
either TheNET or KA-Node RECONNECT to THAT node and then issue a connect 
as shown above. Note: It has come to our attention that those systems using old TNC1 
code will not accept all digit fields, substitute o for 0 and i for 1 in the all digit field 
and you will be successful. Disconnect codes can be found on the KBIBD-4 PBBS, 
filename is DISCO.COD. Please address questions to KBIBD@KBIBD or 
W2VY@KD6TH. This switch brought to you courtesy of RATS. Enjoy 73 Tom 
W2VY 
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$EOF 
END 


NODE Manhattan 
ADDRESS 212456 
PATH KD6TH-3 
END 


NODE LittleFalls 
ADDRESS 201744 
PATH N2DSY-3 
END 


NODE Clifton2 
ADDRESS 201779 
PATH W2VY-9 
PORT 1 

END 


NODE Montclair 

ADDRESS 201256 

PATH W2VY-12 Via KBIBD-2 
END 


USER KD6THbbs 
PATH KD6TH4 
PORT 1 

MAXVC 0 

END 


Route to Nodes Manhattan LittleFalls 
Calls for 

207 802 617 508 413 203 401 

518 607 212 718 716 516 914 315 

end 


Route to Node Manhattan 
Calls for 
212456 


end 


Route to Node LittleFalls 
Calls for 

201744 

end 


Route to Node LittleFalls 
Calls for 

609 215 717 202 

end 

WRITE we2vy-3.tbl 

QUIT 
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Using the ROSE X.25 Packet Network 
Thomas A. Moulton, W2VY 
Radio Amateur Telecommunications Society 
Forward by 
J. Gordon Beattie, N2DSY 


Forward - RATS Open System Environment 


The Radio Amateur Telecommunications Society (RATS) is dedicated to the 
improvement of communications systems in the Amateur Radio Service. This 
objective has been guided by individuals who are willing to develop software, operate, 
and use systems which push the current state of the art. Our packet switch, the ROSE 
X.25 Packet Switch, and communications server, ROSErver/PRMBS, have from their 
inception been ambitious projects providing increased functionality to the users and 
network management. These systems were developed to support communications 
using conventional packet radio equipment. Any AX.25 TNC user can access a 
network of ROSE switches, and likewise any WORLI-compatible packet bulletin board 
system can exchange mail with ROSErver/PRMBS. 


The objective was not another home-grown packet switch or BBS, but to add 
features needed by the users and network management while also facilitating 
interoperability with (or through) other networks. The vehicle for this 
interoperability was the then emerging Open Systems Interconnection Reference 
Model (OSI-RM) developed jointly by ISO (the International Organization for 
Standardization) and the CCITT (the International Consultive Committee on 
Telephone and Telegraph). Adherence to the model has provided a modular 
framework in which protocols could be tested, used, and replaced as new solutions 
(software and hardware) became available. 


We chose to base our systems on OSI because it is a blueprint for 
communications not bound to the design methodologies or marketing objectives of 
private companies like IBM or DEC, or of governmental agencies such as the USS. 
Dept of Defense. Instead, these protocols have been developed and agreed upon by 
both user groups and telecommunications carriers. This blueprint defines the various 
aspects of communications in terms of a seven-level stack. For example, the switch 
provides all required network services needed to interconnect remote users. 


These include: 

Connection - creating a data path through a network 

Data - transfer of data between users will be free of: Most bit-errors; 
Sequencing errors; Undetected packet loss Undetected packet 


duplication 


Clearing - the orderly termination of communications. 
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The OSI reference model is the blueprint that was applied to facilitate the 
evolution of the ROSErver/PRMBS Message Handling System. This system began its 
development as a packet bulletin board system (or PBBS), but has outgrown this label 
by adding interoperability support for CCITT X400 Message Handling System and 
DoD Internet RFC822 message headers, providing for remote file and database 
requests, and remote execution of applications for a user. The system is progressing 
toward support for Directory Services, CCITT X.500 and Management Information 
Services, ISO 9596. 


The progress of OSI-based development has been fraught with difficulties, 
including apathy, "Why Change?", limited resources of developers; the collection of 
dialogues that became known as the "protocol wars". Many of these problems 
occurred because we recognized the impact of OSI very early and as such were faced 
with no base of software or expertise from which to build and many of the required 
standards were not yet defined, or were defined poorly. These difficulties have been 
overcome, since the momentum of the interest in OSI protocols to support multimedia 
electronic mail (X.400), directory services (X.500), and other applications in the 
marketplace today has helped to fuel our efforts now that a larger community exists 
for the exchange of ideas and problem resolutions. 


In any communications environment there are always real and artificial 
boundaries where special handling is needed for communications to occur. In amateur 
radio we have local, regional and area nets for traffic handling, while these are 
geographically based boundaries they are artificial, since a moderately equipped HF 
station can easily cross those boundaries. In the commercial land-line based 
communications systems these boundaries also occur, and in fact are encouraged in 
order to facilitate management of the equipment involved such as modems, telephone 
lines, microwave stations, etc. The term Domain is one term that is used to describe a 
large collection of systems that interoperate in a cooperative manner. 


A domain name or identifier is assigned to specific collection § of 
communications systems to identify the political or management group responsible for 
proper operation of the systems. In order to keep the size of the list of Domain 
Identifiers to a minimum the identifiers are based upon a tree-like structure, "njit- 
eies.mailnet.edu” is an example of a system name where "edu" is the domain name for 
the educational/university communications networks and "mailnet" is a domain within 
the "edu" domain, or a sub-domain. There can be many levels of domains. The 
management group responsible for the top level domain can add sub-domains as 
needed without having to notify the groups managing the other top level or global 
domains, This allows flevihilitv that ts cerecially important to dynamic and fast 


growing networks, such as networks found in the Amateur Radio Service. 


In order to fully integrate the worldwide Amateur Radio Service into the 
global OSI community we needed a unique domain identifier for OSI-based Amateur 
Radio systems. This identifier had to account for national identity in order to provide 
the basis for recognition by the regulatory bodies in each nation. This objective had 
one serious logical caveat: we did not want to request a piece of the global domain 
name space from each country with an Amateur Radio activity. To do so would have 
been a nightmare of paperwork and expense. What was needed was a global Domain 
Identifier for the Amateur Radio Service. ISO and CCITT recognized needs of 
certain activities and organizations such as Amateur Radio when they devised the 
global domain name scheme. Under ISO is a place for "Identified Organizations" (ISO 
6523). Since the Amateur Radio Service is recognized as a global service by the 
International Telecommunications Union (ITU), the International Consultive 


Committee for Radio (CCIR) and the International Amateur Radio Union (IARU), 
we approached ISO for a global domain assignment. After some discussion the 
International Code Designator (ICD) identifying the Amateur Radio Service was 
issued. With the Amateur Radio ICD, OSI-based Amateur Radio systems will be 
known by, and accepted by, non-Amateur systems operating throughout the world. 


RATS will continue the development of user applications to support and 
expand the needs of the Amateur Radio community. We will continue to work with 
other individuals and groups to cooperatively develop new and innovative applications 
and support systems. 


Introduction to the ROSE X.25 Packet Switch 


The ROSE X.25 Packet Switch is a connection-oriented, Open Systems 
Interconnection packet switch which conforms to the CCITT Recommendation X.25 
and provides the user with a functionally rich network interface. The user interface 
to the ROSE X.25 Packet Switch has been designed with the average user in mind. 
Current users who are familiar with networking using digipeaters (C CALLSIGN VIA 
DIGI, DIGI) will find that we have continued this basic concept in the ROSE X.25 
Switch user interface. 


The network will accept data from you and will notify you if there is a 
possibility that data has been lost. The network is 100% reliable unless you are 
otherwise notified. 


Users no longer need to know each step through the network to get to the 
desired destination. The network will handle all routing of connections as defined by 
the routing tables that the network manager has set up. 


The only two things you need to know to make calls using the ROSE X.25 
Packet Switch are the call sign of the switch local to you, and the network address 
(Area Code/Exchange in USA), of the point you want to exit the network. It’s like 
knowing where the telephone is in your house and knowing the phone number 
(Telephone Network Address) of the person you are calling. 


Future applications will provide directory information, similar to 555-1212, and 
other applications that the system manager may choose to upload, such as Clusters or 
Conferencing/Round-Tables. 


System Overview and Features 


Written in the C language by Thomas A. Moulton, W2VY, the ROSE X.25 
Packet Switch is based on the popular AX.25 Link protocol and the CCITT X.25 
Packet protocol. The use of the C language allows rapid "porting" of the software to 
other hardware. 


ROSE X.25 Packet Switch offers the following features: 
* Support for AX.25 Level 2 Users - Any standard TNC. 


* Support for X.25 Level 3 Users - BBS can directly interface with network; 


allows more efficient support for multiple simultaneous users on one 
BBS. 
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* Enhanced Digipeater Support - Higher throughput due to fewer retries 
through one switch. 


* Faster Response Time - Switch is will retransmit information as needed 
using Hop-by-Hop Acknowledgements providing higher throughput. 


* Online Information - Information/Help bulletin. 


* FCC and foreign Government (PTT) acceptable AX.25 Level 2 SOURCE 
and DESTINATION Identification - the call signs of both the station 
of origination and termination appear at each end of the connection. 


* Station Identification integrity maintained - Call signs traverse the network 
without ANY changes. 


* Proper Transmitter Licensee Identification - Switch always identifies its 
transmissions with its own call sign, not the call sign of ANY user. 


* Simple Addressing - Only need to know the address of the desired exit point 
of the network, not all the intermediate steps, true Implicit Addressing. 


* State of the art addressing - Addressing is based on the universally accepted 
telecommunications numbering plan. 


* Network Determined Routing - Network manager determines best path, 
eliminating need for broadcasting of routing information to other 
switches. 


* Dynamic Route Selection - Network will automatically attempt alternative 
paths to remote switches. 


* Predetermined Network Paths - Network manager tells each switch which 
paths to use, will not attempt impossible links because another switch 
was heard during a band opening. 


* Easily Extendible Networking Plan - no need to re-learn how to connect to 
another station because of a new switch being added. 


* Support for Emergency Operations - A switch can be added to the network 
to provide service from the afflicted area without modifications to the 
existing network. 


* Security System for Remote Control - authentication of user who requests to 
view or modify configuration. 


What ROSE Provides 


The ROSE X.25 Packet Switch allows users to connect transparently through 
the Amateur Packet Network to a remote station without the worry of setting up 
connections on a step-by-step basis. All a user needs to do is connect through the 
local switch specifying the remote station’s network address. 


Before ROSE, you had to know the call sign of each digipeater/node in the 
path to reach the station. 


To connect to a station with a ROSE X.25 Packet Switch you only need to 
know the call sign of your local switch and the network address (telephone area code 
and exchange) of the switch local to the station. 


For example, to connect to W2VY from anywhere in the USA; 
C W2VY via (call sign of Your local switch), 201478 
It’s as easy as dialing a telephone. 
Disconnecting from a Station 


Before we get into the various ways you can issue connect requests through a 
ROSE X.25 Network, it is always good to know how to get out! You just disconnect 
like you normally would, if you are using a BBS send the "BYE" command, if you are 
talking to another person hit Control-C and type "D" at the "cmd:" prompt. Don't 
worry about doing something wrong, it won’t bother the switch, if you find something 
that does then I’ve got a bug to fix! Please tell me! 


Information Bulletin 


The switch contains a configurable information message which can be used for 
network information, meeting notices and any text that is desired by the network 
manager. To get this message you just need to connect to the switch and enter return. 
If your local switch is N2DSY-3 you would just type: "C N2DSY-3". When you get the 
“*“ CONNECTED message hit return. You will then receive a line indicating the 
version (release date) of the switch and the text that was loaded by the manager. The 
version is important to know when reporting any bugs. When all the text has been 
sent, the switch will automatically disconnect. 


Local Digipeating 

This mode of operation is straightforward and provides a familiar mode of 
operation to continue WITHIN the local network. The ROSE X.25 Packet Switch will 
only digipeat frames with just ONE call sign (its own) in the "via" field of the AX.25 
frame. The digipeat call sign is usually the call sign of the switch with a "-2" suffix, 
and the switch call sign is generally the station call sign with a "-3" suffix. In any case 
the suffix of the digipeater will be one less than the suffix of the switch. 

For the N2DSY-3 switch the following will work: 

"C N2FWI V N2DSY-2" 
But the following will be ignored: 


"C N2FWI V N2DSY-2,KD6TH-S5 


Because of the extra digipeater field, you may need to use local switching and 
an exit digipeater, see below. 
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Networking with ROSE 


There is only one new concept for users to learn in order to use the advanced 
networking capabilities of the ROSE X.25 Packet Switch. Each switch has a unique, 
local, six-digit "address." This address is the telephone area code and the exchange of 
the location the switch is serving. This address is used to indicate to the network 
where the station you want to communicate with is located. 


Local switching 


Instead of digipeating you may want to use the advanced functionality of the 
switch to reduce channel overhead and increase the overall throughput. If you want 
to connect to another station that uses the same switch (N2DSY-3, address 201744 in 
this case) that you use, you can do this as shown; 


For example: "C N2FWI Via N2DSY-3,201744" 
(where you want to connect to N2FWI) 


In the preceding example you specified N2DSY-3 because that was where you 
entered the ROSE X.25 Network, and you specified 201744 because that was where you 
wanted to leave the ROSE X.25 Network. In this case both the entry and exit points 
were the same location, like a digipeater. 


This initially looks like a two hop digipeater connection, but in reality the 
ROSE X.25 Packet Switch gets into the picture and makes the connection more 
reliable. The switch will receive the connect request from you, establish a connection 
with you, and then attempt to establish a connection with N2FWI. This arrangement 
provides less congestion within the network because the acknowledgements are only 
between adjacent stations. 


Multi-switch networking 

In order to connect to another station at a remote switch one must know the 
address for that switch. If KB7UV uses the switch "718956" a user would type: "C 
KB7UV V N2DSY-3,718956" to connect to him. In later versions the network will have 
support for directory services enabling you to use the actual telephone number of the 
Amateur as the address instead of being required to know their local switch address. 
Entry and Exit Digipeaters 

If the nearest ROSE X.25 Packet Switch is not local to you, you may need to 
include an extra digipeater address. For instance if K2MFF-2 is the digipeater you 
need to access the nearest switch (N2DSY-3), then you could use a connect command 
such as; 

C WA6KJD Via K2MFF-2,N2DS Y-3,619372 
A digipeater may also be needed at the exit point of the network: 

C WA6KIJID Via N2DSY-3,619372,W A6KJD-2 
As well as Both: 


C WA6KJD Via K2MFF-2,N2DS Y-3,619372,W A6KJD-2 


Monitoring Transmissions 


Let us first look at what happens when you set up a connection. For the 
purpose of example we will look at a network consisting of two switches. 


201744 609426 
Little Falls Hightstown 
W2VY KBIBD 


When I want to connect to Bob, KBIBD, I type: 
C KBIBD Via N2DSY-3,609426 
Which will cause my TNC to transmit: 
W2V Y>KBIBD,N2DSY-3,609426 <C> 
Where the <C> means that it is a Connection request. 
At this point N2DSY-3 will accept the connect request by sending: 
KBIBD>W2V Y,609426,N2DSY-3* <UA> 


Where the <UA>® is an "Unnumbered Acknowledgement" confirming and accepting 
the Connection request. 


Note that N2DSY-3 is marked (*) as the transmitting station. 

At the other end the connect request will exit the network with KA2VLP-3 sending: 
W2V Y>KBIBD,201744,K A2VLP-3* <C> 

Note that KA2VLP-3 is marked (*) as the transmitting station. 


Assuming Bob's station is on the air and not busy, he will accept the connect request 
by sending: 


KBIBD>W2VY,KA2VLP-3,201744 <UA> 
And his TNC will print to the terminal: 
™* CONNECTED TO W2VY VIA KA2VLP-3,201744 


This indicates the correct path to W2VY for Bob. 
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How to determine where a connection originated 

When monitoring a channel you will see the switch call sign preceded or 
followed by a six-digit number. This is the area code and exchange of a switch within 
a ROSE X.25 Network. 
Example: 

If you were to see a monitored frame such as: 

W A6KID>W2VY,619372,N2DSY-3* <I>:Carol says Hi! 


Where the <I> indicated the transmission contains Information. 


This would indicate that the N2DSY-3 switch was transmitting information to 
W2VY on behalf of WA6KJD who is at Switch address 619372. 


And if you saw: 
W2V Y>WA6KID,.N2DSY-3,619372 <I>:Hi Dad, back on HF yet? 
Would be a frame sent by W2VY going to WA6KJD@619372. 


Connections with DX Stations look about the same but have an extra numeric 
field: 


VE7TAPU>W2V Y,3020,615423,N2DSY-3* <I>: Hi Tom. 


Is a frame from Canada (Data Country Code 3020), Area Code 615-423. For a 
complete list of DCC’s see Appendix B. 


ROSE X.25 Packet Switch Messages 

m* Disconnect “™* nnnn" 

This message is sent when your connection to the other station is cleared. The four- 
digit number (nnnn) describes the reason for disconnection. For your convenience the 


following table is a list of the codes that are normally seen. The first two digits are 
only important to this table. 





X.25 Name Value Explanation 

DTE Originated 0000 The other station disconnected 
Number Busy 0100 ‘The other station is busy 

Congestion 0500 Retry Count Exceeded 

Out of Order 0900 Network link not operating 

Not Obtainable O0DO00 No known path for address specified 
Ship Absent 3900 No response from station 


In the future these will be replaced with phrases with more meaning. 


Appendix A contains a complete list of codes used by the ROSE X.25 Packet 
Switch. 


mae Reset ™ nnonn” 


This message is sent when a RECONNECT command was issued or the link 
went through a level 2 "Link Reset", to notify you that there may have been some data 
lost. For the complete list of X.25 Cause and Diagnostic codes see Appendix A. 





| } = 2 CtCt—“‘«i‘érEYPiNattiON 
DTE_Orig 0092 The other user issued a REConnect 
Congestion 0792 A Network Link issued a REConnect 


Tips and Tricks 

Can't type full numeric digipeater field: 
If you own a TNC from the vendor that does not allow numeric fields 
(TAPR TNC-1 based TNC’s) you may exchange any 1’s for I’s and/or 0's 
for O’s and the switch will translate it for you. Don’t worry about 


incoming connect requests as they don’t place the same limitation on 
received frames. 
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Appendix A 
CCITT X.25 Cause Codes used by the ROSE X.25 Packet Switch 


The clearing (disconnect) codes are comprised of two parts, the first two digits are the X.25 
Cause, indicating the general reason for the failure and the second two digits are the X.25 
Diagnostic to indicate the specific reason for the failure. 


CCITT X.25 Name Value Explanation 





DTE Originated 00 The other station disconnected 
Number Busy Q1 The other station is busy 

Invalid Facility 03 internal error 

Network Congestion 05 Retry Count Exceeded 

Out of Order 09 Network link not operating 

Access Barred 0OB* Not used 

Not Obtainable 0D No known path for address specified 
Remote Procedure 11 internal error 

Local Procedure 13 internal error 

RPOA Out of Order 15* RPOA Not operational 

Reverse Charge 19* Reverse Charging not subscribed to 
Incompatible Dest. 21* Incompatible Destination 

Fast Select 29* Fast Select Not subscribed to 

Ship Absent 39 No response from station 


Gateway Proc Error Cl* Gateway Detected Procedure Error 
Gateway Congestion C5* Gateway Congestion 


* Currently not used, should not be seen. 


Table 1 - X.25 Clearing Cause Values 


CCITT X.25 Name _ Value _ Explanation 


DTE Originated 00 The other station re-connected 
Out of Order 01 * 
Remote Procedure 03* 
Local Procedure OS * 
Network Congestion 07 Link Reset on Network Trunk 


Remote Operational 09 * 
Network Operational OF * 
Incompatible Dest. 11* 

Network OutofOrder 1D * 
Gateway Proc. Error Cl * 
Gateway Congestion C3* 
Gateway Operational C7 * 


* Currently not used, should not be seen. 


Table 2 - X.25 Resetting Cause Values 


Appendix A 
CCITT X.25 Diagnostic Codes used by the ROSE X.25 Packet Switch 


Value 
Q1 (01) 
02 (02) 
17 (11) 
19 (13) 
20 (14) 
21 (15) 
22 (16) 
23 (17) 
24 (18) 
25 (19) 
26 (1A) 
27 (1B) 
29 (1D) 
33 (21) 
36 (24) 
38 (26) 
39 (27) 
4] (29) 
43 (2B) 
44 (2C) 
71 (47) 
72 (48) 
76 (4C) 
120 (78) 
127 (7F) 
146 (92) 





Invalid P(S) - Internal sequencing error 
Invalid P(R) - Internal sequencing error 
Invalid X.25 Packet for R1 State 

Invalid X.25 Packet for R3 State 

Invalid X.25 Packet for P1 State 

Invalid X.25 Packet for P2 State 

Invalid X.25 Packet for P3 State 

Invalid X.25 Packet for P4 State 

Invalid X.25 Packet for PS State 

Invalid X.25 Packet for P6 State 

Invalid X.25 Packet for P7 State 

Invalid X.25 Packet for D1 State 

Invalid X.25 Packet for D3 State 
Unidentifiable Packet 

lilegal Packet on unassigned logical channel 
Packet too short 

Packet too long 

Restart packet on non-zero logical channel 
Unauthorized Interrupt Confirm Packet 
Unauthorized Interrupt Packet 

No logical channel available 

Call Collision 

Facility not provided when expected 
Temporary Routing Problem 

Maintenance Action 

Retry count exceeded for data packet transmission 


Table 3 - X.25 Diagnostic Codes Used 
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Appendix B - CCITT Data Country Codes 


Zone 2 





DCC Country or Area 


202 
204 
206 
208 
212 
214 
-16 
218 
220 
7795 
226 
228 
230 
232 
234 
238 
240 
242 
244 
250 
260 
262 
266 
268 
270 
272 
274 
276 
278 
280 
284 
286 


Greece 

Netherlands 

Belgium 

France 

Monaco 

Spain 

Hungarian People’s Republic 
German Democratic Republic 
Yugoslavia (Socialist Federated Republic of) 
[taly 

Romania (Socialist Republic of) 
Switzerland (Confederation of) 
Czechoslovak Socialist Republic 
Austria 


United Kingdom of Great Britain and Northern Ireland 


Denmark 

Sweden 

Norway 

Finland 

Union of Soviet Socialist Republics 
Poland 

Federal Republic of Germany 
Gibraltar 

Portugal 

Luxembourg 

Ireland 

Iceland 

Albania 

Malta (Republic of) 

Cyprus (Republic of) 

Bulgaria (People’s Republic of) 
Turkey 


Zone 3 





DCC Country or Area 


Canada 

St. Pierre and Miquelon 
United States of America 
United States of America 
United States of America 
United States of America 
United States of America 
United States of America 
United States of America 
Puerto Rico 

Virgin Islands (USA) 
Mexico 

Jamaica 

French Antilles 
Barbados 

Antigua 

Cayman Islands 

British Virgin Islands 
Bermuda 

Grenada 

Montserrat 

St. Kitts 

St. Lucia 
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Zone 3 (Cont. 


DCC Country or Area 


360 
362 
364 
366 
368 
370 
372 
374 
376 


St. Vincent 

Netherlands Antilles 

Bahamas (Commonwealth of the) 
Dominica 

Cuba 

Dominican Republic 

Haiti (Republic of) 

Trinidad and Tobago 

Turks and Caicos Islands 


Zone 4 
DCC Country or Area 


404 
410 
412 
413 
414 
415 
416 
417 
418 
419 
420 
421 
422 
423 
424 
425 
426 
427 
428 
429 
430 
431 
432 
440 
450 
452 
454 
455 
456 
457 
460 
470 
472 


India (Republic of) 

Pakistan (Islamic Republic of) 
Afghanistan (Democratic Republic of) 
Sri Lanka (Democratic Socialist Republic of) 
Burma (Socialist Republic of the Union of) 
Lebanon 

Jordan (Hashemite Kingdom of) 
Syrian Arab Republic 

Iraq (Republic of) 

Kuwait (State of) 

Saudi Arabia (Kingdom of) 

Yemen (Arab Republic) 

Oman (Sultanate of) 

Yemen (People’s Democratic Republic of) 
United Arab Emirates 

Israel (State of) 

Bahrain (State of) 

Qatar (State of) 

Mongolian People’s Republic 

Nepal 

United Arab Emirates (Abu Dhabi) 
United Arab Emirates (Dubai) 

Iran (Islamic Republic of) 

Japan 

Korea (Republic of) 

Viet Nam (Socialist Republic of) 
Hong Kong 

Macao 

Democratic Kampuchea 

Lao People’s Democratic Republic 
China (People’s Republic of) 
Bangladesh (People’s Republic of) 
Maldives (Republic of) 


Zone 5 
DCC Country or Area 


Malaysia 

Australia 

Indonesia (Republic of) 
Philippines (Republic of) 
Thailand 

Singapore (Republic of) 
Brunei 

New Zealand 

Guam | 
Nauru (Republic of) 


Appendix B - CCITT Data Country Codes 


Zone 5 (Cont) 
DCC Country or Area 


537 
539 
540 
541 
542 
543 
544 
545 
546 
547 
548 
549 


Papua New Guinea 

Tonga (Kingdom of) 
Solomon Islands 

New Hebrides 

Fiji 

Wallis and Futuna Islands 
American Samoa 

Gibert and Ellice Islands 
New Caledonia and Dependencies 
French Polynesia 

Cook Islands 

Western Samoa 


Zone 6 
DCC Country or Area 


602 
603 
604 
605 
606 
607 
608 
609 
610 
611 

612 
613 
614 
615 
616 
617 
618 
619 
620 
621 
622 
623 
624 
625 
626 
627 
628 
629 


631 
632 
633 
634 
635 
637 
638 
639 


641 
642 


645 


Egypt (Arab Republic of) 

Algeria (Algerian Democratic and Popular Republic) 
Morocco (Kingdom of) 

Tunisia 

Libya (Socialist People’s Libyan Arab Jamahiriya) 
Gambia (Republic of the) 

Senegal (Republic of the) 
Mauritania (Islamic Republic of) 
Mali (Republic of) 

Guinea (Revolutionary People’s Republic of) 
Ivory Coast (Republic of the) 
Upper Volta (Republic of) 

Niger (Republic of the) 

Togolese Republic 

Benin (People’s Republic of) 
Mauritius 

Liberia (Republic of) 

Sierra Leone 

Ghana 

Nigeria (Federal Republic of) 

Chad (Republic of the) 

Central African Republic 
Cameroon (United Republic of) 
Cape Verde (Republic of) 

Sao Tome and Principe (Democratic Republic of) 
Equatorial Guinea (Republic of) 
Gabon Republic 

Congo (People’s Republic of the) 
Zaire (Republic of) 

Angola (People’s Republic of) 
Guinea-Bissau (Republic of) 
Seychelles 

Sudan (Democratic Republic of the) 
Rwanda (Republic of) 

Ethiopia 

Somali Democratic Republic 
Republic of Djibouti 

Kenya (Republic of) 

Tanzania (United Republic of) 
Uganda (Republic of) 

Burundi (Republic of) 

Mozambique (People’s Republic of) 
Zambia (Republic of) 


Zone 6 (Cont) 


DCC Country or Area 


646 
647 
648 
649 
650 
651 
652 
653 
654 
655 


Madagascar (Democratic Republic of) 

Reunion (French Department of) 

Zimbabwe 

Namibia 

Malawi 

Lesotho (Kingdom of) 

Botswana (Republic of) 

Swaziland (Kingdom of) 

Comoros (Federal and Islamic Republic of the) 
South Africa (Republic of) 


zone 7 





702 
704 
706 
708 
710 
712 
714 
716 
722 
724 
7 
732 
734 
736 


740 
742 
744 
746 
748 


DCC Country or Area 





Belize 

Guatemala (Republic of) 

El Salvador (Republic of) 
Honduras (Republic of) 
Nicaragua 

Costa Rica 

Panama (Republic of) 

Peru 

Argentine Republic 

Brazil (Federl Republic of) 
Chile 

Colombia (Republic of) 
Venezuela (Republic of) 
Bolivia (Republic of) 

Guyana 

Ecuador 

Guiana (French Department of) 
Paraguay (Republic of) 
Suriname (Republic of) 
Uruguay (Oriental Republic of) 
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AMTEX 
NAVTEX-Like Dissemination Procedures for Amateur Radio 


Paul Newland, ad7i 
Post Office Box 205 
Holmdel, New Jersey 07733 


INTRODUCTION 


This paper outlines procedures for transmitting and receiving amateur radio bulletins via 
MF/HF radio that are compatible with NAVTEX' equipment. NAVTEX transmissions are 
made using AMTOR FEC with specific character strings at the beginning and end of 
messages. These character strings permit receiving equipment to identify and ignore 
messages that have already been received without error. It’s estimated that over 20000 
amateur radio operators already have NAVTEX decoding equipment. As of this writing both 
the AEA PK-232 and MFJ-1278 multi-mode controllers have the ability take full advantage of 
transmissions compatible with NAVTEX. These decoders could be used to provide automatic 
reception of amateur radio bulletins without repeatedly printing the same message during 
subsequent broadcasts. It’s a simple matter for any MF/HF amateur radio station that 
transmits bulletins using AMTOR FEC to include the proper strings at the beginning and end 
of messages so that those messages become NAVTEX compatible. This paper outlines 
transmission and reception procedures that are compatible with existing NAVTEX decoders. 


NAVTEX 


The NAVTEX radio network consists of many transmitters throughout the world on 518 kHz 
that are used to broadcast marine safety information to ships within 100 nautical miles of 
shore. AMTOR FEC (CCIR 476-2 Collective Broadcast Mode) is the specified transmission 
format (modulation and code) for NAVTEX. NAVTEX< stations typically transmit a 20 to 40 
minute broadcast every six hours. Transmit times are staggered to ensure that transmitters 
serving adjacent areas cause little or no interference. 


Any equipment capable of receiving AMTOR FEC can copy NAVTEX bulletins, but non- 
NAVTEX equipment doesn’t have the ability to ignore messages that have already been 
correctly received. NAVTEX compatible simply means that the decoder can automatically 
ignore messages that have already been printed without error. 


NAVTEX messages always begin with a line that consists of "ZCZC B,B,B,B,"; where 
ZCZC is used to mark the beginning of a message; the symbol B, denotes coverage area; the 
symbol B, denotes type of message; and the symbols B,B, denote a 2 digit sequence number. 
Additionally, each message ends with a line that consists of "NNNN". 


1. NAVTEX is defined by CCIR Recommendation 540-1 (1982). 


The advantages of encapsulating the message between the strings ZCZC and NNNN, coupled 
with AMTOR’s feature of error detection and correction, allows a NAVTEX decoder to print 
a message only once, no matter how many times the message is broadcast, provided the 
message was received with zero (or only a few) errors. 


When a message is received the NAVTEX decoder checks the NAVTEX message ID 
(B,B,B,B,). If that message has not already been received, error free, the message will be 
printed. When the end of message marker is found (NNNN) the NAVTEX decoder counts 
the number of uncorrectable errors that occurred during the reception of that message. If the 
count is below some threshold (the threshold should be user programmable, perhaps from 0) 
to 10) the NAVTEX message ID is retained in the NAVTEX decoder’s memory. During 
additional broadcasts of the same message the NAVTEX decoder won’t print the message 
because it has been flagged as already received correctly. 


Priority messages and emergency messages should always use a B,B, value of 00. NAVTEX 
decoders always print messages, every time received, when the B. B, value i is 00. 


AMTEX —- NAVTEX 


Because the NAVTEX system operates on a specific frequency and the message content 
relates to marine safety, radio amateurs should not use the term NAVTEX to describe their 
transmissions, even though the transmission format is exactly the same as that of NAVTEX. 
Instead, I recommend that the term AMTEX be used to describe a transmission system that is 
compatible with NAVTEX decoders. AMTEX retains the NAVTEX concepts of 
encapsulating a message between the strings ZCZC and NNNN as well as using the "two 
alpha symbols — two numeric symbols" message ID format. AMTEX simply represents a 
name change and the reassignment of the message ID symbols for amateur radio needs. 


MAKING BULLETINS AMTEX COMPATIBLE 


Making amateur radio bulletins compatible with AMTEX involves adding only two lines to 
each bulletin or message. One line is inserted just before the first line of the current header 
(i.e., just before the "OST DE W1AW" line for W1AW bulletins). Another line is inserted just 
after the line that includes the closing "AR" pro-sign. 


The line inserted at the beginning of the message consists of 9 characters: "ZCZC 
B,B,B,B,". The string ZCZC is a constant while the symbols B,, B, and B,B, denote 
variables. (a single space character separates the "ZCZC" and "B,B, B, B," strings). The 
variable B, denotes the organization that originated the bulletin. Most bulletins are issued by 
the ARRL and, based on the AMTEX procedures document (see Appendix 1), the variable 
B, would be set to the letter "A". The variable B, denotes the type of bulletin. For example, 
general bulletins would have the variable B, set to "G", propagation bulletins would have the 
variable B, set to "P", etc. Again, see the AMTEX Procedures document (Appendix 1) for 
other symbol assignments. The sequence number B,B, is arbitrary (except for 00). However, 
a new sequence number should be used for each new bulletin that uses the same values of B, 
and B,. Bulletins from W1AW would typically set the value of B,B, to be the same as the two 
least significant digits as the BID number. However, for ociocity or emergency bulletins, a 
BB, value of 00 would be used because this would ALWAYS cause printing devices to show 
the message, every time it’s received, even if it has already been correctly received. 183 


AMTEX PROCEDURES 


The proposed AMTEX procedures are outlined in Appendix 1. An example of text that is 
formatted for AMTEX< is shown in Appendix 2. The current AMTEX procedures should be 
considered a starting point and subject to revision in the future. However, because of the 
large embedded base of NAVTEX equipment already in the hands of amateur radio 
operators it’s unlikely that any changes to the AMTEX procedures would render it 
incompatible with existing NAVTEX decoders. 
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Appendix 1 — AMTEX Transmission and Reception Procedures 


I. AMTEX transmissions should meet the following requirements. 


1. 





Radio frequency emissions should conform to the specifications of AMTOR FEC 
(CCIR 476 or 625 Collective Broadcast Mode). 


The transmitted character through-put rate should not exceed 180 characters 
(printable or non-printable) in any 30 second period (i.e, about 60 WPM). 
Whenever phasing signals (idle signals) are transmitted, a minimum of six 
consecutive phasing signal pairs (PS1 in the RX position — PS2 in the DX position) 
should be transmitted. 

Redundant letter and figures shift characters should be used in the message to 
reduce garbling. 

The format of transmissions should be 


B,B,B.,B 


234 | 


EOM Signals | 
| CR/LF | Message | NNNN | CR/LF CR/LF Oa... a 


in which 


Phasing is the AMTOR FEC phasing (also known as idle) sequence 
(PS1-PS2-PS1-PS2....) 


ZCZC denotes that the message ID follows 
Space is a single space character 
CR/LF are the carriage return and line feed characters 


B,B,B.B, is the message ID 
123% £ 185 
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Message _is the message to be disseminated 
NNNN defines the end of the message 


EOMa _ is the AMTOR FEC end of message signal(s). Two seconds (15 
symbols) would be the ideal length of the EOM signal. However, 
a transmission as short as 420 milliseconds (three symbols) is 
acceptable. 


II. AMTEX reception devices should meet the following requirements. 


1, 


The printer should only be activated if the message ID (B,B,B,B,) is received 
without errors. 

Facilities should be provided to avoid printing the same message several times at the 
same station when that same message has already been printed with no more than a 
few errors. 


The necessary information for the recommended operation of (2.) above should be 
deduced from the message ID (B,B,B,B,) and possibly the message contents. 


A message should always be printed if B,B, 1s 00. 
Devices should be capable of ignoring messages with undesired B, values. 


Devices should be capable of ignoring messages with undesired B, values, except 
that messages which have B, values of "A", "B" or "D" may not be ignored if the B, 
value is desired. 


ITI. Message ID Symbol Assignments 


1. 


Message Originator Identifier — B 


The B, symbol indicates the source of the message and should be assigned as 
follows: 


A ARRL issued bulletins 
CRRL issued bulletins 

I IARU issued bulletins 

J JARL issued bulletins 

S AMSAT issued bulletins 

X Miscellaneous (none of the above) 

All Others _ All other characters are available for future assignment. They may be 
used without advance notice. 


2. Message Type Identifiers — B, 


The B, symbol indicates the type of message and should be assigned as follows: 
A Emergency bulletins (always printed at least once) 

B Priority bulletins (always printed at least once) 

D RESERVED (always printed at least once) 

E DX bulletin 


ou KR QO 


xX 
All Others 


General bulletin 

Keplerian bulletin 

Propagation bulletin 

Satellite bulletin 

Miscellaneous (none of the above) 


All other characters are available for future assignment. They may be 
used without advance notice. 


Sequence Number — B3B, 


The sequence number corresponds to a particular set of B, and B, symbols. The 
sequence number increments by one to create the next message ID for the next 
message with the same set of B, and B, symbols. The sequence numbers range 
from 01 to 99, with 01 being the first value of the sequence. When the sequence 
number is incremented past 99 it rolls over to 01 (00 is skipped). Any special 
message(s) should use the sequence number "00" as that will cause the message to 
be printed (or stored) every time it is received. 
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Appendix 2 — Example AMTEX Transmission 


Below are examples of ARRL bulletins with the proper AMTEX lines added. The added 
information for AMTEX is shown in a larger point type and in bold face. 


ZCZC AG71 

OST DE WIAW 

HR ARRL BULLETIN NR 71 ARLBO71 
FROM ARRL HEADQUARTERS 
NEWINGTON Cr JULY 9, 1988 

TO ALL RADIO AMATEURS BT 


PREREGISTERED CLUBS IN WYOMING WILL BE SIGNING THE 
SPECIAL 200 BICENTENNIAL PREFIX FROM 0001 UTC JULY 9 
THROUGH 2359 UTC JULY 15. 

=s=s=== text deleted for brevity ===== 

SHERIDAN AR LEAGUE, W200GUX, 

UNIVERSITY ARC, NQ200Q AR 

NNNN 


ZCZC AP27 

QST DE WIAW 

HR PROPAGATION FORECAST BULLETIN NR 27 ARLPO27 
FROM ARRL HEADQUARTERS 

NEWINGTON CT JULY S, 1988 

TO ALL RADIO AMATEURS BT 


DURING JUNE THE SOLAR FLUX HIT THREE NOW CYCLE 22 HIGI#IS. 
THE MONTH BEGAN WITH THE FLUX AT 150, A SWEPT 
AWAY WHEN IT ROSE TO 165 

===== text deleted for brevity ===== 

AMERICAN SUNSPOT NUMBERS FOR JUNE 23 THROUGH 29 WERE 
BETWEEN 77 AND 111 WITT! A MEAN OF 96.6 AR 


NNNN 


ZCZC AS93 

QST DE W1AW 

HR SATELLITE BULLETIN NR 192 ARLS192 
NEWINGTON CT JULY 10, 199° 

TO ALL RADIO AMATEURS BT 


ALL INDICATIONS ARE THAT THE SECOND AO13 KICK MOTOR BURN 
ROCA) EXACTLY AS PLANNED AND THAT THE SATELLITE HAS 


JULY 12 Uo9 00102 AT 65W ‘UO11 0033Z AT 43W FOL2 0119Z 
AT 46W RS10 0039Z AT 171W AR 


A Multi-Channel IBM PC Packet Interface 
Henk Peek, PAOHZP J 


This paper describes a universal medium speed packet interface for the Isa (IBMPC) 
bus. The system consists of one or more 4 channel Isa bus boards and external mo- 


dems. 


Multiple boards can be interconnected to form one single interface with a 


single interrupt vector and daisy chain interrupt priority logic. General software can be 
used. There are no special initialization actions required. The connections between the 
lsa bus boards and the external modems are opto isolated. 


Introduction 


Many packet stations take an interest in the use of 
more speeds and frequencies. However addition of 
an extra TNC for each mode and frequency used 
simultaneously is necessary. Over four TNCs the 
async ports of the IBMPC will be not standardized 
and costly. There is an other solution: direct HDLC 
AX.25 interfaces. But, it is difficult to find cheap 
HDLC boards with more then two HDLC channels. 
Otherwise the number of available Isa slots define in 
large stations the channel limit. A few years ago 
PEICHL has designed his own multichannel Atari 
AX.25 packet interface (ref 1). The design described 
below is based on the experience with the PE1CHL 
interface. 


The OptoPcScc Interface 


The OptoPcScc is a short size Isa interface board 
equipped with 2 8530 SCC chips, offering four 
channels on a board. Small stations operate with one 
board and larger stations with multiple boards. Those 
multiple boards can be coupled to a_ single 
multichannel interface with one common interrupt 
and interrupt vector fetch mechanism. The 8530 chip 
handles asynchronous and synchronous formats. 
Each channel has its own external clock divider for 
full duplex synchronous operation. An OptoPcScc 
board is interfaced to the 1O port space of the Isa 
bus, mapping both SCCs to 8 ports. The base IO 
port of the first SCC control port is 0x150. The 
address of the adjunct data port is the next IO port. 
Each following SCC channel control port is adjacent 
to the data port of the SCC channel. For the 
second OptoPcScc board a jumper adds 8 to the 
board base |O port. In the few situations that more 
than 8 SCC channels are required, the flexibility of 
the ISA bus decoder PAL can be used to address the 
adjunct ranges of |O ports. One large multichannel 
SCC interface can be constructed from multiple 
OptoPcScc boards by daisy chaining the INC to the 


OUTC connectors with short 5 wires cables. The first 
board in the chain has a free INC connector and is 
automatically the master of the chain. All other 
boards are slaves and the last one has a free OUTC 
connector. The master OptoPcScc board generates 
the Isa bus interrupt for all the boards. Each 
OptoPcScc board has a latch for the generation of 
the intack signal. All the intack latches are set by 
writing to port 0x170. The intack signal indicates an 
active interrupt acknowledge cycle. During this 
cycle, the interrupt vector select chain settles. A read 
command to port 170 places the SCC interrupt vector 
on the Isa bus and resets afterwards the intack 
latches. The interrupt vector read cycle selects only 
one single board databuffer by monitoring the board 
IEl1 (Interrupt Enable In) for HIGH and the board 
IEO2 (Interrupt Enable Out) for LOW. A single 8530 
SCC on a board can be used by interconnecting IEO 
pin 6 and JE! pin 7 of the absent 8530. When your 
software doesn't support the intack latch interrupt 
fetch mechanism, it can apply the general but slower 
method of polling each 8530 chip for interrupt. 


Opto Isolated Modem Interface 


Most multiple transmitter packet stations have 
groundioop problems. In practice this results in 
whipping the TNC settings when you are working 
on the HF bands, or PC noise radiated by the 
modem cables. Opto isolators, introduced in an 8 
channel backbone switch for the Dutch packet 
network, are applied at the OptoPcScc board to 
minimize these effects. The PC847 opto couplers are 
cheap and support maximum 20K baudrate. Higher 
speeds can be supported by using surface mount 
opto couplers on a small surface mount DIL board. 
The high speed Rx and Tx opto couplers are to 
expensive for general use. An Isa interface board 
has a limited space for back side connectors. This is 
one of the reasons to reduce the number of modem 
signals, to a minimum: Rx, Tx, DCD and RTS. Some 
modems require a synchronous Tx clock. Only 
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phase and the frequency are not standardized. For 
half duplex operation you can generate the modem 
transmit clock from a small interface. The SCC 
receiver phaselock is used to synchronize the SCC 
transmitter clock to the interface clock. To play this 
trick, the SCC channel must be placed in the external 
loopback mode and an HDLC synchronize flag 
signal, generated from the interface clock, must be 
applied to the SCC Rx input. The same interface can 
be used to convert the current loop signals to RS232 
or TTL signals. A common 37 pin Male D connector 
is used for the modem connections of the 
OptoPcScc board. The modems have a 9 pin female 
D connector. The connection between the 
OptoPcScc and the modems can be made of a single 
flatcable which is spliced at the modem side in four 
cables. In most situations it is much safer to use 
shielded cables to minimize noise radiation and RF 
pickup. The shield of the modem cables must be 
only on one side connected to one of the ground 
pins of the 9 pin modem cable D connector, the other 
side must not be connected to the 37 pin D 
connector and isolated from each other. 


External V202 Modem with Opto Interface 


This TCM3105JL modem design is included in this 
paper to show that is simple, to realize a currentloop 
modem interface. You must have currentloop V202 
modems for the most frequencies which you are 
using the OptoPcScc board. The number of 
necessary components is low making it is easier to 
realize a new modem instead of interface an existing 
one. The modem is made on an 4 by 7cm single 
sided printed circuit board. On one short side the 9 
pin female D connector for currentloop data is 
mounted and on the other side an 5 pin audio DIN 
for the transceiver connection. The transceiver cable 
also connects the +12V power supply. The modem 
uses internally +5V supply. The +12V supply only 
has to meet the specifications of the 78L05 regulator. 
vite LOW power Consumption of the modem can be 
supplied by nearly any transceiver or portofoon. In 
the preferred mode of operation (J1 closed), this 
modem generates only audio with RTS active. In this 
mode more modems can be operated in parallel by 
wiring the modem transceiver sides parallel. An 
transmit audio switch is not necessary. The modem 
can also generate continuous audio output with J1 
open. A 30 second watchdog timer is incorporated. 
The PTT switch is a BS170 mosfet protected by a 47V 
zener diode. The on resistance is low enough to key 
nearly any transceiver. 
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Practical experience 


This project is build on Printed Circuit Boards. At the 
time of writing (20 August 1989) a few boards are 
running. Series of double sided plated-through 
printed circuit boards with gold plated edge 
connector fingers will be made. Contact the author 
for availability. 
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ABSTRACT 


This paper presents the design and successful implementation of a local area network 
bridge based on the link layer AX.25 packet radio protocol and the AppleTalk Personal Network 
on the Macintosh computer. Operated as a duplex communication channel between interconnected 
networks of computers, the packet radio system provides the transmission of the network layer 
data packets. A working prototype of the bridge was developed for slow rates. A higher-speed 
bridge will require a faster packet radio and faster hardware for the bridge. 


1. INTRODUCTION 


Local area network (LAN) technology has brought about an evolution in computer 
communications by sharing data and resources among a large number of users in localized areas. 
Now, this LAN concept is becoming too restrictive and larger (national and international) networks 
are required. To facilitate the creation of such large networks, internetwork connections are used 
to transfer data between the networks and provide data translation for different systems. An 
internetwork connection is called a bridge if the LANs are homogeneous, or a gateway if they are 
inhomogeneous. These interconnections can be made through either telephone lines, fibre optics, 
radio frequencies (HF, VHF and UHF), microwave terrestrial links, or satellite links. One of the 
affordable interconnects could include packet radio over the amateur bands. This would allow a 
number of interesting applications, including long distance education. 


This paper presents the design and implementation of a bridge based on the AX.25 amateur 
radio packet protocol [1 and 2] and the AppleTalk Personal Network [3] as used on the Macintosh 
computer [4]. AppleTalk has been selected as an example of a practical implementation of the 
International Organization for Standardization (ISO) Open System Interconnect (OSI) model [5], 
permitting interactions between computers and peripherals either on a single network or on 
different nets interconnected through bridges and gateways. Firstly, the requirements of a local 
area network bridge are presented, and two solutions are proposed: (i) a single-connection internet 
bridge, and (1i) a multiple-connection bridge capable of interconnecting multiple networks 
simultaneously. Next, the implementation of both the bridge and the interfaces created between the 
bridge, together with the packet radio network and the AppleTalk network are presented. Finally, 
a testing procedure and preliminary results are discussed. 
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2. THE BRIDGE DESIGN 
2.1 The AppleTalk Network to Bridge Interface 


The interface between an AppleTalk network and the bridge process consists of system 
routines (calls) developed by Apple to perform input and output on the network, and a buffer 
manager to store the packets from the network in local memory. Involved in the interface specified 
for the AppleTalk network is a link layer communication protocol used to enable the AppleTalk 
hardware to transfer data over the network in an organized and error free manner. The AppleTalk 
Link Access Protocol (ALAP) is used for the link layer transmission which allows the network 
hardware to (i) route the packets to an appropriate node, and (ii) recover the packets from the 
network. 


The transfer of the packets from the network is carried out by first receiving the packets 
from the network and then storing the packets in memory. The packet receiving task is provided 
by a protocol handler which is an interrupt driven routine responsible for retrieving the data from 
the AppleTalk hardware (MPP driver) and placing the data in a buffer provided by the bridge. To 
facilitate the required asynchronous and rapid reception of packets, a swinging buffer mechanism 
[6] must be employed to reduce the possibility of packet overrun caused by slow removal of full 
packets by the bridge. The first five bytes of the packet include the ALAP header (the destination 
node, the source node, and the type of packet), as well as the size of the Datagram Delivery 
Protocol (DDP) which is responsible for the internetwork communication. 


The operation of the protocol handler is very simple and essentially involves the rapid 
transfer of data from the AppleTalk network hardware to main memory. Upon reception of the 
first five bytes of an ALAP packet, an interrupt is generated by the MPP driver and the protocol 
handler is invoked. The protocol handler first verifies that the packet was received correctly. If the 
Frame Check Sequence (FCS) is validated correctly, the first five bytes are then transferred into a 
buffer provided by the bridge. Next, an asynchronous read is issued which reads the remainder of 
the packet into the buffer as it arrives. The protocol handler finally indicates that the buffer is 
completed by setting the pointer to the buffer to NULL. If the protocol handler finds the buffers 
not empty, the pending ALAP packet is discarded, and the higher-level protocols used in the 
network become responsible for the retransmission of the lost data. 


| LOCAL NETWORK BRIDGED NETWORK 
>ROTOCOL HANDLER PROTOCOL HANDLER 


BUFFER 


MANAGER 


APPLETALK 
| OUTPUT QUEUE | 





Fig. 1. The data flow path of the packets in the bridge. 
As shown in Fig. 1, the sole purpose of the buffer manager is to maintain empty buffers 
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for the protocol handler while transferring completed packets onto one of three input queues for 
later processing. The three input queues are: (i) the AppleTalk queue (used for transmission of 
packets on the local network), (ii) the bridge processing queue, and (iii) the remote network queue 
(connected through the packet radio network, as described in Section 2.3). 


The requirement of the bridge to execute as efficiently as possible dictates the method of 
transferring data from the protocol handler to the queues. Since buffer transfers require a large 
amount of processing time, the implementation of the buffer manager requires that only pointers to 
the buffers are moved to the queues while the actual packets remains intact in memory. 
Furthermore, new buffers are allocated to the protocol handler during noninterrupt processing 
periods to avoid memory manager conflicts and system inconsistencies. 


2.2 The Packet Radio Network to Bridge Interface 


The packet radio to bridge interface has no formal definition in any available sources. 
Therefore, the main guide to follow during development is to provide a functionally equivalent 
interfaces to both the local AppleTalk network and the remote network connected through the 
packet radio network. Similar to the AppleTalk interface, a protocol handler is employed to 
retrieve the ALAP packets from the packet radio network. The data transmitted over the radio link 
is organized into packets according to the AX.25 link layer protocol. As shown in Fig. 2, this 
system is also very amenable to the use of digipeaters in relaying packets between the network 
bridges to extend the minimum area of coverage by the packet radio link. Global interconnection 
of LANs can be achieved through this implementation since satellite repeater stations also exist on 
the amateur bands. 


APPLETALK 
_ NETWORK 





Fig. 2. Single-connection AX.25 internetwork bridges. 


The AX.25 protocol operates at the link layer of the ISO-OSI model and is used to 
communicate the AppleTalk network layer packets between the interconnected networks without 
contributing any modifications to the AppleTalk network layer data. In this way, any protocol 
could have been employed by the packet radio link without posing any problems at the network 
layer, but the AX.25 is a reliable communication protocol with guaranteed delivery, thus nearly 
eliminating the probability of network errors, increasing the overall efficiency of the bridge through 
fewer AppleTalk packet transmissions. 


The interface to the packet radio network to the bridge consists of the transfer of the 
AppleTalk packets to and from an unmodified terminal node controller (TNC), such as the all- 
mode KAM [7]. The TNC is responsible for the assembly and disassembly of the AX.25 packets. 
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Error free transmission and packet ordering is maintained by the TNC according to the protocol. 
This implementation removes the burden of maintaining the AX.25 protocol from the host 
processor, thus allowing a faster execution of the remainder of the bridge process. Using this 
implementation, the number of AppleTalk networks which can be connected by one bridge is 
limited to two (see Fig. 2). The reason for this limitation is that the TNC supports only a single 
connection facility at a time. 


The packet radio protocol handler is also an interrupt driven process. In this case, 
however, the TNC is connected to the Macintosh computer through the serial port. The interrupt is 
created when the serial drivers receive data from the TNC over the serial port. To enable the 
reading of an ALAP packet, system read calls are performed on the serial ports to receive a 
specified amount of data. When the data is received, an interrupt is created and a completion 
routine of the system call is executed. The bridge reads the data from the TNC by first issuing an 
asynchronous read command to obtain the header of the ALAP packet. When the header is 
received, the size of the packet is known, and a subsequent call can be made to read the remainder 
of the packet. The two read calls are invoked through the interrupt completion facility of the 
Macintosh computer. 


The swinging buffer mechanism is employed again for the packet radio interface. Also, the 
buffer manager described above for the AppleTalk network interface is responsible for the creation 
of new buffers for the packet radio protocol handler as well the transfer of packet buffers from the 
protocol handler to the three input queues. 


2.3 Bridge Processing and Protocol Support 


The main components of the AppleTalk network bridge involve (i) the routing of packets 
between AppleTalk networks, and (ii) the maintenance of the network protocols. The bridge 
process consists of a dispatch loop, calling each of the specific tasks that provide packet routing 
and protocol support. 


The dispatch routine is responsible for the management of the bridge process. In simple 
terms, the dispatcher is the main program of the bridge process, and consists of an infinite loop 
executing the required operation on the packets. In each cycle of the dispatcher, the following 
routines are executed: (i) the buffer manager, as described above, (ii) the queue manager, and (iii) 
the timers and window management processes. 


The queue manager routine, CheckQueues, monitors and processes the packets on the 
three input queues. There are also three output queues: AppleTalk queue, internet queue, and 
bridge processing queue. They are checked once through each dispatch loop, with equal 
processing on each queue. The packets found on the AppleTalk queue are transmitted on the 
AppleTalk network through a LAPWrite system call, while packets on the internet (packet radio) 
queue are transmitted on the packet radio network by sending the ALAP packet to the TNC through 
a TNCLAPWrite call. The third queue, the bridge processing queue, contains the packets which 
require protocol processing or which supply routing information to the bridge through the Routing 
Table Maintenance Protocol (RTMP). 


In order to facilitate homogeneity in the network, the bridge protocol processes must be 
designed according to the protocol definition outlined by Apple. The entire set of the AppleTalk 
protocols for OSI Layer 3 (network layer) through Layer 4 (transport layer) were implemented in 
the bridge. These protocols included the DDP, the AppleTalk Transaction Protocol (ATP), the 
RTMP, the Zone Information Protocol (ZIP) , the Echo Protocol (EP), and the Name Binding 
Protocol (NBP). 
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2.4 A Bridge with Embedded AX.25 Protocol 


The above discussion of the packet radio bridge interface assumed the use of the packet 
assembler/disassembler (PAD) of the TNC. An alternative packet radio communication link 
incorporates an implementation of the AX.25 protocol as an integrated component of the network 
bridge software package. In this implementation, the TNC is used only as a modem and a 
transmitter activator for the radio. The full AX.25 protocol is implemented in the bridge package. 
Each half bridge would be able to create numerous connections to other half bridges on the 
network, reducing the amount of inter-AppleTalk network routing that would have to take place. 
This reduction in routing would reduce the amount of traffic on the air and throughput of the 
internetwork could be increased. 


A dynamic routing table is employed to map the AppleTalk networks to the logical 
connection established between the bridge processes. One socket on each bridge implementation 
acts aS a connection acceptor so that dynamic connections are possible. Once a connection is 
established, a secondary socket is opened, and the logical connection is maintained between the 
calling socket and the secondary socket. The listen socket automatically updates the network 
routing table when a connection request is obtained from the packet radio network. The AX.25 
network table is interfaced to the AppleTalk routing table such that dormant nodes can be 
eliminated. Figure 3 shows an example of a possible connection scheme using the AX.25 
embedded bridge. As in the single-connection internet implementation, a digipeater system could 
be used to extend the transmission distance of the bridges. 


APPLETALK 
__ BRIDGE 


| APPLETALK 
NETWORK 





Fig. 3. Multiple-connection AX.25 internetwork bridges. 


3. THE PACKET RADIO INTERFACE IMPLEMENTATION 


This section describes the implementation of the packet radio to bridge interface employed 
in the AppleTalk bridge. The code is in Lightspeed C and the overall listing takes 68 pages [8]. 
As shown in Section 2.2, the interface is provided as the access point to the serial drivers on the 
Macintosh computer, using the protocol handler and buffer manager. Two distinct phases of 
operation of the packet radio are involved in the AppleTalk network bridge: (i) link establishment 
and (ii) packet transfer. The operation and implementation of the connect and data transfer phases 
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is described below. 
3.1 Connection Establishment Phase 


The connection establishment sequence is used to create a logical connection between the 
two halves of the AppleTalk network bridge. To allow for dynamic connections, two modes of 
connection establishment must be defined: (i) passive connection, and (ii) active connection. In 
active connection establishment, the bridge process initiates a connect request to another bridge 
process. The bridge process to which the connection establishment is addressed is operating in 
passive connection sequence. This process waits for connections on an AX.25 port and upon 
receiving a request, establishes the connection. 


When the bridge is first started, the user is required to enter the amateur radio call sign of 
the desired network or a default call sign to place the bridge in passive connection mode. The TNC 
connect routine is then executed to open and initialize the serial drivers. Following a successful 
driver opening, a synchronize routine is executed. The purpose of the synchronization is to 
establish coordination between the bridge software commands and the execution of the TNC. 


If a connection is requested by the user, the call sign of the remote bridge process is 
encoded into a connect command. The request is then sent to the TNC, and the system then enters 
an asynchronous wait for acknowledgement phase. If the bridge has been initialized to perform a 
passive connect, the same routine is executed, as described above for connection 
acknowledgement. In order to indicate a connection has been established, the TNC returns 
*** Connected to xx000xx, where x20 is the call sign of the remote AppleTalk network bridge. 


Upon reception of the connection acknowledgement, the TNC is placed in transparent 
mode for packet transmission. In the transparent mode, the TNC transmits all data without 
modification. All interbridge communications are performed while the TNC is in transparent 
mode. The TNC remains in the transparent mode until a disconnect request is issued and the TNC 
receives the BREAK signal. Any error encountered during the connection process causes the 
bridge process to enter the passive connection mode to wait for incoming connection requests. The 
passive connection routine executes through the interrupt and completion routine mechanism 
supplied by the operating system. 


The disconnect sequence is executed either prior to closing the bridge down or when it is 
detected that the other half of the bridge has been terminated. The disconnect routine is responsible 
for forcing the TNC back into command mode, disconnecting the connection to the other bridge, 
and closing the serial ports. The initiation for termination of a bridge connected to a dormant 
network is supplied by the RTMP protocol through the network aging process. 


3.2 Packet Transmission Phase 


The major operation of the packet radio interface involves the transmission of the ALAP 
packets between the bridged networks. For this communication, the serial drivers are employed to 
communicate with the TNC and packet radio network. In order to communicate with the TNC, the 
ports have to be configured properly. This operation is provided by the SerialOpen function 
which opens the input and output serial drivers and initializes the communication rate and data size. 


The two read routines responsible for receiving the packets from the TNC, TReadSize 
and TReadRest, form the packet radio protocol handler. Operated as asynchronous read calls, the 
interrupt driven completion routine facility of the operating system allow for asynchronous 
reception of the ALAP packets from the packet radio network. TReadSize is responsible for 
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reading the size of the next ALAP packet. This routine reads the first five bytes of the packet. 
Upon completion, an interrupt is generated, and the TReadRest routine is called to read the 
remaining bytes of the packet. Again, on completion of reading the entire ALAP packet, another 
interrupt is generated and the TReadSize routine is executed to read the size of the next packet 
coming from the bridged network. The packets received are placed in the swinging buffer 
mechanism described in Section 2.2, and the buffer manager stores the completed packets in 
memory and supplies the routines with new buffers. If no empty buffer exists when a new packet 
is received, the packet is discarded by reading it into a dead buffer and a LostPacket counter is 
incremented to record system performance. 


The write routine used to transmit data to the bridged network, TNCLAPWrite, closely 
resembles the operation and calling syntax designed for the LAPWrite described in the Macintosh 
standard. An ABusRecord is passed to the write routine which contains the information such as 
the pointer to the data block, the size of the data to write, and the port reference number to access. 
At the end of this routine, the completion routine is executed which returns to the user supplied 
ABusRecord the actual number of bytes written and the error status created through the write 
request. Only a single outstanding write is allowed through TNCLAPWrite. If a connection is 
not established, the write returns success. This operation is required to allow the bridge process to 
continue the execution of its heart beat transmission for the RTMP. The fields of the LAP header 
on the packet are completed before the packet is transmitted. 


Two other routines, 7NCWrite and TNCRead, have been created to support transmission 
of ASCII text to the TNC for connection establishment and termination. Furthermore, a 
SerialClose procedure is executed to terminate all communication requests over the serial port and 
to shut down the serial input and output drivers. In order to remove all outstanding read and writes 
on the operating system queues, a Kill/JO call is required. The KillJO call is required because 
outstanding reads after a driver close are not terminated and the bridge system would not be 
restartable without performing a warm rebooting of the computer. 


4. SYSTEM OPERATION AND TESTING 
4.1 Bridge System Verification 


The bridge protocols were verified in a test setting consisting of a serial link interconnecting 
two networks A and B, as shown in Fig. 4. One computer on each network, a bridger, was 
dedicated to executing the bridge software. The serial ports of the two bridgers were connected 
together, while the network ports were connected to the corresponding AppleTalk network bus. 
Three other computers were situated on each network to run utility programs capable of testing the 
bridge system. One computer on each network was used as a packet sender. The packet sender 
computer executed a utility program called POKE packet which has the ability to format and 
transmit any AppleTalk packet. The third computer on each network was a packet watcher, in 
that every packet sent on the network was monitored by this program. The utility program PEEK 
was executed on the packet watcher node. This utility is essential in verifying that the bridges were 
responding with the correct data. The fourth computer ran the throughput test procedure 
described in Section 4.2. The AppleTalk protocols implemented on the bridge were tested first. 


4.1.1 Verification of RTMP and ZIP 


The RTMP protocol is used for maintaining the routing table. To do this, a "heart beat" 
packet is transmitted by the bridges at a ten-second interval, and an RTMP packet is expected from 
every active bridge on the internet within the same time interval. The testing of this protocol can be 
best completed by first starting up one network, then starting up the other bridge a short time later. 
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The RTMP packet sent on the network contained only the routing tuple of the local Network B, 
(network address $4000). When the second bridge is started, a new routing tuple for Network A 
(network address $3000) is observed. The second network is then shut down. After 40 seconds, 
the routing tuple for Network A disappears. This is due to the aging mechanism of RTMP so that 
a dynamic routing table can be maintained without the need of transmission of a shut down packet. 
The ZIP packet is transmitted only once at the initial connections of the two packets. After this first 
ZIP request, both networks know the zones of each other and no further ZIP packets are required. 


NETWORK A 
___ APPLETALK NETWORK BUS 


a fos vue) BE ———— fave) ——— foo oe) 
BRIDGER SENDER WATCHER TESTER 


NETWORK 5B 
APPLETALK NETWORK BUS 
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—— (.---) wee ...-} —— (.--- 
BRIDGER SENDER WATCHER 
Fig. 4. Test apparatus for bridge verification. 
4.1.2 Verification of NBP 


An NBP request packet was transmitted from a node on Network B. The bridge process of 
Network B sends a look up packet to Network A. Network A does a broadcast on its own network 
to obtain the name. The node with the name being looked for then sends a directed packet to the 
requesting node on Network B. 


4.1.3 Verification of Echo Protocol 


Two types of echo protocols exist for short and long echo packets. The short echo packet 
is sent out on the local network. In the test, the bridge node was sent an echo packet from one of 
the packet transmitters. The first packet marked with a ZONE 1 in the data field is the initial packet 
transmitted. The second packet is the echoed packet. The test shows that the source and 
destination addresses, 1F and 83 are reversed in the echo return packet. This also occurs in the 
transmission of the long echo packet except that in this case the packet is sent across the bridge. 
The returned echo packet has both the source and destination node numbers and network numbers 
reversed. 
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4.2 Throughput Tests and Discussion 


One of the major factors in the operation of a packet radio bridge is the expected 
throughput. On the packet radio link, the transmission rate is 1200 bits/sec. This, however, is a 
simplex communication channel and, thus, the system is limited to 1200 bits/sec in one direction at 
atime. Recall that the transmission rate of the AppleTalk Network is 230 kbits/sec. If we take the 
case when only one network is transmitting across the channel with no return traffic, we get a ratio 
of 230 to 1.2. Therefore, the amount of data which must be queued on a busy network could 
easily overflow the memory of the computer and cause a system crash. This large difference 
between queue input and output rates will cause large delays to occur in the networks operation. 


| Let us obtain the best-case time during a one way transmission by sending a packet on a 
clear network. The one-way delivery time, T, is calculated as the sum of the times of each leg of 
the trip and can be expressed as 


L 
T=BN > (1/R) 
si (1) 


where B is the number of bytes in the packet, N is the number of bits in a byte, L is the number of 
legs in a packet trip, and R; is the data transmission rate on the jth leg in bits/sec. For example, the 
best-case time required to transmit a 100-byte packet from a node on network A to a node on 
network B through the packet radio bridge operating at 1200 bits/sec is 


T = 100 * 8 (1/230000 + 1/1200 + 1/230000) 
= 674 msec (2) 


It is seen that the bulk of the communication time is spent in the bridge communication section of 
the link. This problem can be overcome by increasing the speed in the packet communication link 
{9 and 10]. Another method of increasing the number of bytes transmitted per second is by 
employing a data compression technique. The advantage of the latter technique is the bandwidth 
preservation. 


During the initial testing, a large number of buffer overruns were observed on a busy 
AppleTalk network. Because of this, the dispatcher was modified to execute the buffer manager 
multiple times in each dispatch cycle. This modification decreased the number of discarded 
packets, but increased the number of packets backed up in the processing queues. This backing up 
of the processing queues may continue until a saturation point is reached, past which the number of 
a packets increases until the queues begin to empty again, creating available resources for 

e bridge. 


A test has been devised to determine the average round trip transmission time required to 
send a packet. A test utility program outlined is executed on one of the computers, with all other 
computer being idle. The program then transmits a user specified number of packets using the 
echo protocol. The time of transmission is stamped onto the packet when it is transmitted. Upon 
receiving the return packet, the time is compared and the round trip delay is obtained. This test is 
very important to study possible improvements to the bridge. 


We have transmitted text and other objects such as pictures over the bridge. Interactive 
graphics can be achieved between different LANs. 
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5. CONCLUSIONS 


The implementation of a packet radio bridge for local area network is currently possible 
although quite limited. The major limitations occur as a result of the low speed transmission rates 
available on the packet radio communication link. The AX.25 Link Level protocol employed in 
amateur packet radio provides a strong data transmission medium in which packets transmitted are 
guaranteed to reach their destination, a necessity for efficient internetwork communications. Based 
on the present work, the following extensions are proposed: (i) Study into the throughput 
problems of the network bridge must be undertaken to suggest areas of improvement; (ii) For a 
general purpose bridge, an on-board implementation of the AX.25 protocol should be employed; 
and (iii) Dedicated hardware, as opposed to the general-purpose Macintosh computer, should be 
employed to increase processing speed while reducing hardware costs. 
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D AM A —- A NEW METHOD OF HANDLING PACKETS? 


Detlef J. Schmidt, DK4EG 
Steinbrecherstr.22 D-3300 Braunschweig 
Translation: Mark Bitterlich, WA3JPY 


Lately it seems we are hearing more and more stories about 
hams who are having trouble using their local node or digipeater. 
It seems that the user has no trouble hearing the digi, but the 
digi doesn’t seem to hear the user at all. The symptoms almost 
match those where the receiver at the digi site is either dead or 
close to it. While that kind of failure is always a possibility, 
it is not the subject of this article. 


The condition that this paper will talk about is one where 
the above symptoms do actually occur, but not from any lack of 
receiver sensitivity. Instead it is due to the digi’s receiver 
hearing too many signals all at once and the remote user pretty 
much gets lost in the "noise." 


The reason for this becomes obvious when we consider that 
while all the users may hear the digi/node just fine, they in 
many cases don’t hear each other. Thus in some cases more than 
one station will transmit at the same time causing packet 
collisions. This situation is referred to as "a hidden stations" 
problem, and for remotely located users access to his or her 
favorite digipeater can become difficult to impossible during 
rush hour periods. 


This is not a new problem, and in fact there are other 
services experiencing the same difficulties. A real world 
example is ships on the open sea trying to gain access to a 
communications satellite. 


Several different experiments have been made to overcome 
this dilemma on amateur packet radio. One possible solution that 
is being pursued is through the use of full duplex digipeaters 
(BTMA), however there are several disadvantages to this approach. 
In a full duplex system the hardware expense will normally be 
much higher and the system will occupy two frequencies but will 
only realize the maximum throughput of one. A better approach 
might be to increase the throughput by reducing the collisions on 
a single channel system rather than spreading the load onto two 
channels. It would be ideal if we could incorporate a system that 
did this with something so minor as a software change (such as 
replacing the EPROM in a TNC) or by changing some operational 
parameters. 


One of the methods used that attempts to solve the hidden 
station problem while still using a single frequency is called 
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DAMA (Demand Assigned Multiple Access). A description of this 
method follows. 


In a connection oriented protocol environment, an end user 
will try to connect to the master (satellite) by means of a 
slotted ALOHA method. Collisions might occur during this phase, 
but they are tolerable since they are relatively rare. Once a 
connect request is recognized by the master, the connecting 
stations identification is added to a polling list and from this 
point on the master controls all connected stations. Permission 
to send data is granted by means of polls which might be included 
in ACK packets or even in transferred data frames. So in this 
case a user will only be allowed to transmit after receiving 
"permission" in the form of a poll sent from the master station. 
Once permission is granted several frames might be transmitted in 
a block. However, if the user does not respond within a given 
time frame (say around 1/2 second) then the master assumes that 
the poll got clobbered or the user never received it for some 
reason. The master then passes permission to transmit to all 
other active stations and when completed comes back to the first 
user and gives him another chance. 


On the other hand, if the user (slave) actually receives the 
poll and replies with sent I-frames, the master will not 
acknowledge them until the next time around after serving all the 
other active stations. If when polled by the master the user 
responds with an empty frame (Receive Ready/Final), then the 
master will reduce the user in polling priority and will skip him 
on the next time around. 


As the activity on the frequency increases, the polling 
priority of inactive users might be further decreased, but when 
these stations respond with an I-frame they will again regain 
their original priority. 


If you understand the description just given, you might 
think that you are reading about AX.25 level-2 protocol and this 
is why DAMA has a chance of working over amateur packet radio. 
AX.25 L2 provides all the protocol elements that are needed to 
implement DAMA and no new syntax is required. Most of the new 
functions required could be obtained simply by patching existing 
operational parameters while the rest could be achieved by making 
some minor changes to the TNC’s firmware. 


So how do we actually go about incorporating DAMA using AX.25 
protocol? 


Due to the fact that there are no new syntax elements 
required, the following description will only use standard Ax.25 
terms. Since CSMA as well as DAMA is used, please interpret all 
further references to DAMA as CSMA-DAMA. The term "POLL" used 
throughout this text in no way refers to the poll bit in the 
control field of packet frames and this bit remains unchanged to 


204 


ensure compatibility. The different phases of the protocol will 
be described separately below. 


Connect Establish: 


When a node attempts to connect to a user, the node adds the 
users ID to it’s polling list and begins to send SABMs to that 
station. If after a certain amount of tries no UA is received, 
the user is assumed to be inoperable and is removed from the 
polling list. 


When a new user starts a connect sequence to the node, he 
begins by sending SABMs to the master in a simple CSMA manner 
duplicating the existing method used today. Collisions are 
possible during this phase, so it might be necessary to repeat 
the SABMS several times until the node replies with a UA. Once 
the node recognizes the users connection attempt, the users ID is 
added to the polling list in a fashion very similar to the one 
now used by TheNet nodes (TheNet userlist) and the node (master) 
is now in control of the uplink users station. After the user 
sends the SABMs and the node replies with a UA, the user replies 
with an RR#0 to signal to the node that it had a successful 
reception of the UA. 


Idle State 


As long as no information transfer occurs between user and 
node, (idles) then the node sends its polls as an RR with the 
corresponding count. If the response by the user is just an RR#, 
then the time until the next poll to this user will be lengthened 
to avoid unnecessary channel load. The exact amount of time 
added is determined by total channel activity. 


If information transfer by other users on the node is high 
(as determined by the number of I-frames being sent) then the 
amount of time added before the next poll occurs to an inactive 
station is longer than in cases where there is only very little 
channel activity. Thus when the frequency is basically clear, the 
waiting times are reduced to a minimum so that no decrease in 
channel throughput takes place. This is the principle of the 
self-alignment mechanism of DAMA, where a channel is always 
regulated to insure its maximum possible throughput. 


If the node ever fails to receive an RR from the user (due 
to a collision of the nodes poll or the users RR response) then 
the node will proceed on to the other stations on its polling 
list. The node will come back and try this station again after 
all other users on its list have been serviced. If after a 
certain number of transmitted polls this station still has not 
answered, then it is considered to be unavailable by the node and 
is then dropped completely from the list. This is analogous to 
those "keep-alive polls" that we have today. 
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Data transfer: Node -> User 


There is no difference between regular CSMA and DAMA in this 
case. Because it is always up to the master (node) to act first, 
it could send one or more I-frames or a poll to the user. The 
user will acknowledge I-frames immediately with an RR#, but could 
also send its own I-frames with the corresponding count (having 
the correct count on the sent I-frame serves the same purpose as 
an ACK with AX.25). The meaning of the Poll/Final bit remains 
unchanged. 


Data transfer: User -> Node 


As mentioned before, the node will send polls to all users 
that are uplinked to it and the user will not respond until it 
receives this poll or an I-frame from the node. It may be wise to 
point out that when a user is polled he must always come back 
with some kind of response, even if it is an RNR#. If the node 
fails to hear any kind of response from the user then it assumes 
something went wrong (such as a collision) and moves on to the 
next user on its polling list. 


This method of always waiting for a poll before transmitting 
is the central aspect used to avoid collisions in a situation 
where hidden stations exist. This is in contrast to the usual 
CSMA method where several stations can actually transmit at the 
same time. Additionally the problem of deadtime collisions is 
resolved. Deadtime refers to the period from when the TNC 
realizes the channel is free and starts transmitting, to when he 
has been on the air long enough for other TNCs to recognize his 
carrier. This is really not a rare case, as exemplified by the 
case where two or more TNCs are waiting for a digipeaters carrier 
to vanish so that they can leap on the frequency. Using DAMA the 
node will not acknowledge received frames the instant it hears 
them. Instead it will first service all the other uplinked 
stations and then come back with an RR# to the sending stations 
I-frames along with a poll to that station. This poll basically 
says "Have you got anything else for me?" 


Disconnecting 


If the master intends to cut the connection, it will send 
the usual DISC-frame to the user. The user will then promptly 
respond with a UA-frame (final bit set). If the node fails to 
receive the UA and again sends a DISC-frame, the user will 
respond with a DM-frame. This is identical to the actual CSMA 
version. 


When the user wants to disconnect from the node, he will 
wait to send his DISC-frame until polled by the master. At this 
point it makes no major difference whether the node responds to 
the user right away with a UA or goes through another polling 
cycle to do so, however an immediate UA is preferred. 


206 


UI-frames 


In CSMA as well as in a DAMA environment, the UI frames are 
treated in a special way. I.E. These frames are used to carry 
some information besides the regular protocol traffic. Normally 
UI-frames are never sent from a user to a node, and it is not 
good headwork to make a habit of making UI-frame direct QSOs on 
the input frequency of a node. However, in contrast to a duplex 
system it is possible to actually do this. So although the rare 
UI-frames will reduce the throughput to the CSMA value, it will 
not drop to the much lower ALOHA value that would occur with a 
duplex digi having a QSO on its input frequency. UI-frames 
originated by the node are no problem since all stations receive 
these frames. 


Other protocol elements 


So we have gone from the beginning to the end in describing 
a complete DAMA session. We have not translated each and every 
AX.25 element into one that has special significance to DAMA. This 
is not required since many of them will keep their initial 
meaning. DM, RNR, REJ, etc will all be used as they were before. 
The only deviation from the pure CSMA version is in the fact that 
the users will only be allowed to transmit these frames after 
receiving permission from the master (node) in the form of a 
poll. The node will only transmit these frames after all other 
users on its list are served by the completion of one polling 
cycle. 


Compatibility of DAMA and CSMA 


One advantage of the DAMA method is that it does not require 
everybody to change everything all at once. However as additional 
users convert their TNCs to work with DAMA the more pronounced 
will become the increase in throughput. Even stations that are 
waiting to switch over could help to increase the areas 
throughput by changing a few operational parameters. For example 
the delay between the reception of a frame and the TNCs response 
(sometimes called T2 or DWAIT) should be reduced to a value under 
1 second. In addition the time interval from when an I-frame is 
sent to when the TNC sends an RR# to ask for a pending ACK, 
should be set to a value that is clearly higher than the time 
between two polls of the master (usually more than 30 seconds at 
1200 baud). 


To fully benefit from DAMA both the node and the user must 
work together in the master/slave relationship. Assuming that 
the users TNC is capable of both the normal and the DAMA mode, 
there still remains the problem of how to tell the user to "turn 
DAMA mode on." There are several ways that this could be done: 


1. Automatic detection of the protocol version by means of the 
protocol identifier byte or reserved SSID-octet-bits of the 


207 


node (Preferred version). 

2. Implementation of a channel specific parameter which controls 
the protocol version. 

3. Implementation of a new UPLINK command besides the current 
CONNECT command. 

4. Implement a further protocol element such as a SARM-frame 
(Similar to X.25) so that at connect time the node could alert 
the user to the increased features. 


In case #1 of the above it would be sufficient to tell the 
user to switch to DAMA mode only once, at connect time. This 
state would then remain in effect until disconnect. However 
Since there is no PID field in SABM-frames this information has 
to be carried in some other way, such as utilizing the dormant 
bit 5 of the master’s SSID address field. It is proposed that 
DAMA test versions set this bit to 0 to convey the necessary 
information to the users TNC. 


Conclusion 


The existing AX.25 version was established in 1982 when 
packet radio was not as widespread as it is today. Most stations 
in the beginning were pretty much equal and there was no 
distinction made between DTE and DCE functions. However with the 
implementation of wide area networks not all stations are 
performing the same function. In fact today the network nodes 
are acting in a DCE function considering their control and 
information exchanging aspects. These functions will be better 
served with the implementation of DAMA. 


The methods discussed in this article could increase the 
throughput on an AX.25 channel tremendously. One advantage is the 
avoidance of system breakdown which occurs with channel overload. 
Using DAMA, the throughput will increase continuously up to its 
maximum. There is no foldback effect like that which occurs using 
CSMA where at a special limit (above ca 60%) the throughput is 
actually reduced. 


There is also a strong "social" aspect of DAMA wherein even 
the weak stations can work through the node reliably without 
being overpowered by stations close to the node. 


It is possible to make direct connections with other HAMs on 
the uplink frequency unlike that of a duplex system. In addition 
the users TNCs still retain the digipeater capability inherent in 
our present simplex system. 


All protocol elements keep their original meaning which 
allows both versions to be utilized on the same frequency, yet 
throughput increases as more and more users switch over to the 
new method. 
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Glossary 


DM Disconnect Mode 

DISC Disconnect Frame 

FRMR Frame Reject 

ha Information Frame 

REJ Reject Frame 

RNR Receive not Ready 

RR Receive Ready 

SABM Set asynchronous balanced Mode 
SARM Set asynchronous Response Mode 
UA Unnumbered Acknowledge 

UI Unnumbered Information Frame 


ALOHA channel access without any coordination 


CSMA Carrier sense multiple access 
BIMA Busy tone multiple access 

DCE Data circuit terminating equipment 
DTE Data terminating equipment 


Connection oriented protocol: All nodes of a network path know 
all other stations that are using this path, at least for some 
time. This version requires more computer power in the network 
nodes but avoids some unnecessary transfer overhead. In contrast 
to this is the connectionless protocol, where packets are simply 
handled over to the next peer (i.e. ‘dumb’ Level-2-digipeating in 
Packet Radio ). 
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Application Software for Packet Radio 


A Packet Chess program is used 
to demonstrate the utility of 
Application software for Packet Radio 


Robert Taylor, KA6NAN 
Dewayne Hendricks, WA8DZP 


Introduction 


To date, there has been little use made in amateur packet radio of application 
software to provide a wide variety of services to the packet community. Most packet 
software delivers a limited range of capabilities such as file transfers, mail and 
database queries (White Pages). We feel that the use of higher levels of applications 
software is possible even given the constraints of today's packet speeds, that can 
offer a wider range of services. We use a program called Packet Chess to 
demonstrate how such services can be delivered. Packet Chess demonstrates how it 
is possible to have a real-time game operate over packet with a graphical user 
interface and at low data transfer speeds. 


Problems with Packet Software 


Current packet software is far too text oriented. There are too many commands 
to memorize and understand. For a new user, the command structure is not 
intuitive. The emphasis on text makes an 'on-the-air' session more work than fun. 
A different approach which would be more user friendly would be the use of 
graphic images. However graphical images are too difficult to utilize because a) 
current packet is slow, and graphical images would take too long to transmit., and b) 
there is a lack of standards, which could be used to exchange graphical information. 


Some solutions using Application software for packet 


What do we mean by application software for packet? When connected 
stations utilize similar software, and this software is specifically written to provide a 
particular service, then we call these programs applications. The Packet Chess 
program described below is an example of this concept, since it is written specifically 
to facilitate the playing of chess. This applications program addresses the problems 
we cited above in a number of ways. 


By making extensive use of a graphical user interface, it eliminates the need to 
memorize a large number of commands. You can present the player with the 
appropriate choices at the appropriate times, making program use much more 
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intuitive. Further, the use of similar application programs reduces the need to send 
large amounts of data in order for the programs to interoperate. Since the programs 
start out with the same "shared data", a program can simply "refer" to data, rather 
than transmit it. For example, in the Packet Chess program, instead of sending the 
entire image of the whole chess board with each move, we can just send the move 
information itself, since the program at the other end already 'knows' what the 
board and pieces look like, and the location of all pieces. This means you can use 
graphical images, without the need to transfer large amounts of data over a 
relatively slow connection. 


PACKET CHESS 
What is Packet Chess ? 


Packet Chess is a program written in 1988 by Dewayne Hendricks (WA8DZP), 
and Rob Taylor (KA6NAN), to demonstrate the utility of a different approach to 
application software on Packet Radio. The program was designed to operate on the 
Apple Macintosh personal computer and to take advantage of the unique user 
interface and capabilities available on that system. Figure 1 below shows the initial 
screen which the player sees once the program is started. At this point, a selection is 
made as to either start the game or to initialize the session parameters. The player 
proceeds with their choice by "clicking" on the appropriate button with the mouse. 


Packet Chess 


Chess over Packet Radio 


by 
Robert Taylor, KA6BNAN 





Dewayne Hendricks, WA8DZP 





Fig 1 
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What the program does. 


Packet Chess permits two people to play chess over packet radio. Our design 
goal was to design the user interface so that the play of the game would be similar to 
what would occur if two players were actually facing each other over a chessboard in 
the same room. The program does NOT play chess, it simply allows two players to 
exchange moves easily. While playing, each player's screen looks like a chess board 
(Figure 2). To make a move, the player just "picks up a piece and moves it". This 
operation is performed by using the mouse to position the cursor over the piece and 
then clicking the mouse to select the piece and then using the mouse to move the 
piece to the desired location. You don't have to worry about commands to your 
computer, or your TNC, or even chess notation. Since all moves are displayed on 
both 'chess boards' at the same time, you simply play chess as normal! 





Ifove “White Fawn4™ 
a74 140 


|Move "Diack Knighi1” 
1232 106 


ORE RS. 


EE ER 


SRR RR 
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How to use Packet Chess 


First, a player enters the opponent's callsign and other parameters for the 
session, and then presses the 'connect' button. Once connected, you just play chess 
by moving the chess pieces! When a chess piece is moved (using a 'mouse’), a text 
string is generated (such as "Move white queen to x y"). This text string is then sent 
automatically to the other program, which then makes the corresponding move on 
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that screen. The players never have to type in any 'command'’, they just play chess! 
The players can send messages to each other at any time. To do this they just enter 
there message in the "Output" window on the chessboard and select the "Msg" 
button. This capability simulates the normal dialog the players would have if they 
were sitting across from each other. There is an option to use a modem instead of 
packet to allow the program to be used over telephone lines. There is also a button 
that causes the entire board to be reset to the starting configuration. There is no 
attempt to validate the legality of any moves. Our goal was not to build a chess 
playing program, but simply allow two players to have a chess game as they 
normally would. 


How was it written ? 


The Packet Chess program was written in HyperTalk™. This language is used 
by the HyperCard™ program on the Macintosh™ computer. HyperTalk was 
selected because the language can easily handle graphical objects and the other 
components of the Macintosh user interface. Since HyperTalk is a high level 
language, the programming was fairly simple. A set of subroutines were written in 
assembly language to send/receive information from the TNC and setup the 
necessary options on the Macintosh serial port. 


On-Line Help 


No matter how ‘easy’ you think your application is, it would probably benefit 
from some level of on-line help. On-line help is available in the Packet Chess 
program.. Figure 3 shows the screen which the player sees when he selects the help 
button on the chessboard screen. The player can use the mouse to select the topic of 
interest by selecting the appropriate index tab at the bottom of the screen. The 
graphical nature of HyperCard allows for an interesting way of presenting help 
information since images of information being discussed can be included in the 
help text. 
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Messages 


into the first line of the box on the lower lefthand side marked Out 
Window’, and press the button (on the right hand side) marked ‘Msg’. 
The ‘Out Window’ may be cleared at any time by striking the Enter’ Key. 


To receive a message, just keep an eye on the ‘In Window’. Both 
moves and messages will be displayed there. Messages will have the 
letters "MSG' at the beginning. A distinctive tone will announce the 
arrival of a message from your opponent. The In Window may be 
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To send a message to your opponent, simply type your message text 
cleared at any time by striking any ‘Arrow key. | 
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Figure 4 shows in detail one of the help screens. All help information is 
available at any time during a game. 


Some ideas for other 'Packet Programs" 


Many other forms of packet could benefit from our new approach to 
application software. For example: emergency communications between hospitals 
could be implemented as a "form" that gets filled out on the computer screen. The 
user would simply 'check-off' which hospitals to send the message to. On receipt at 
the other locations, the message would display/print out in the same format in 
which it was entered. Another example would be emergency co-ordination centers 
could utilize a large collection of maps. The locations of accidents and/or people 
and vehicles could be plainly indicated. Maps could be made to zoom in and out. 
This could be done very efficiently because each site would have digitized forms of 
the maps stored locally. All that would have to be transmitted to the remote site 
would be a simple command like "display map 87E"! All the user would see at the 
remote site is a map of the accident area, and people/vehicles in their reported 
locations, along with any text messages. 


Future Directions 


Although the packet chess program was designed for 'regular' AX.25 packet, 
our current interests are in developing TCP/IP related applications. We want to 
generalize the ability of other applications to interoperate via TCP/IP. There are 
plans to incorporate Inter-Process Communication (IPC) ability into the Macintosh 
version of the KA9Q Internet Protocol Package. The would permit a single, stable 
version of the Macintosh version of the KA9Q package to work with a constantly 
growing set of applications. 


Summary 


Many packet services would benefit from application packet software. This is 
an opportunity for hams to truly "advance the state of the art", especially in the area 
of emergency communications. While much important work is being done in the 
area of network software, we cannot overlook the need for application level 
solutions. Improvements in the ‘ease of use’ and functionality are necessary and 
useful step in the evolution of packet radio. 
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Callsign Server for the 
KAIQ Internet Protocol Package 


by 
Douglas Thom (N6OYU) 
Dewayne Hendricks (WA8DZP) 


INTRODUCTION 


One of the problems we found with packet communications, after we did a fev. 
keyboard to keyboard connections and log-ins to BBS's, was what else does it do for 
us? We can send mail to all these people out there in packet land that we do not 
know, or we can watch messages fly by that don't interest us..... What is missing is a 
true user application. Hmm... We thought, there has to be something we can do for 
the packet community. One afternoon, we were logged into the Internet (a world 
wide computer network) and saw a message that a group of people were putting a 
project together to acquire a copy of the Amateur Radio Callsign database from the 
F.C.C. Great, here it is.... We could put together a service whereby people could 
contact a packet station, and lookup a callsign. This could be an interesting service, 
and if successful, provide something of use to the community. Since we knew one 
of the people involved in getting the data, we contacted him, and got a copy of the 
database. As it turned out, the actual data file is 108 Megabytes in size and contains 
over 435,000 callsigns. Unfortunately, it only contains US callsigns, but that's a great 
start. Each record of the file has in addition to the callsign, both the mailing and 
station addresses, the class of license, previous callsign, renewal/process/expiration 
dates, and even the persons birthdate! Wonderful.... now all we had to do was 
figure out how to give access to this data from a packet station, where was we going 
to store this huge database file, and how do we tell people about it.... 


ENTER THE KA9Q TCP/IP PACKAGE.... 


We were working on another project, porting the KA9Q TCP/IP package to the 
Macintosh, when several people in our area asked the same question. What are we 
going to do with TCP/IP? It is certainly a neat system, but without applications to 
make use of it, it suffered from the same old problem mentioned above. Then the 
light flashed, how about interfacing the callsign database to one of the TCP/IP 
servers... like the finger server. The finger server is a utility built-in to the TCP/IP 
package that allows a remote station to query your station for basic information. 
Great idea said Dewayne (WA8DZP, the programmer who did all the work!), and in 
a few days he had written the initial code to access the callsign datafile. It took 
several more weeks of debugging and testing, but finally we had an extension to the 
finger command. 
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IMPLEMENTATION 


Before we can provide a service, we need to have a place to store the datafile, 
and of course the datafile itself. To start off, we contacted Rusty Carruth (N7IKQ) 
who headed up the project to acquire the data from the F.C.C. Rusty provided a copy 
of the data on a 9 Track magnetic tape. Since our plan was to put the data on a 
Macintosh, the next task was to get the datafile converted into a format that could be 
used. This was done with the help of several people at Apple Computer, who 
moved the data onto a DEC VAX system, from where it was transferred (via 
Xmodem) to a Macintosh with a 300 Meg drive. 


Now that the data was on a Macintosh, we moved it to an AppleShare™ 
fileserver at N6OYU's OTH. Since the Macintosh version of the KA9Q Internet 
Protocol Package supports multiple volume access, the next task became the 
implementation of the software to access the datafile, and return the requested 
callsign information via a packet station. 


From here, Dewayne proceeded to develop the necessary routines required to 
access the datafile. Since the Finger client/server already provided much of the user 
interface we had in mind, it was used as a point of departure. Logic was added to the 
Finger server to look for a '%' as the first character in the parameter string passed to 
it from the user. When this character is received, control is passed to a new module 
which parses the callsign request and accesses the callsign database for the requested 
information. 


This was all fine, but what about all the rest of the packet user's out there that 
do not have the TCP/IP package up and running. Well, as it turns out TCP/IP as 
implemented, will support AX25 connections as well, and even provides a mail box 
function. So additional code to extend the mail box function was added to allow an 
Inquiry of the database. This addition of the Inquire command to the mail box code 
now provides the ax25 connects access to the database. 


Below are examples of how this all works. (Bold-Italic character are typed by the 
user) 


net> finger *twa8dzp@n6boyu<cr> 


SYN sent 

Established 

(N60YU.norcal.ampr.org] 

Name: DEWAYNE L. HENDRICKS 

License: WA8DZP License Class: E 

Mail address: 43730 VISTA DEL MAR, FREMONT, CA 94539- 
0000 

Station address: 43730 VISTA DEL MAR, FREMONT, CA 
Effective date: May. 17, 1988 Expiration date: May. 17, 
1998 

Previous Callsign: Previous Class: A 
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Birthdate: Oct. il, 1945 Process date: May. 1/7, 
1988 


Close wait 
Last ACK 
Closed (Normal) 


Note the use of the %callsign@n6oyu syntax in this command. The typical 
finger command looks like this: finger doug@n6oyu. This will look for a text file 
named ‘doug’ on the system diskette, and copy it's contents to the TNC. With the 
Callsign server extension, we added the % to tell the finger server to lookup the 
following callsign in the database, and return that information to the TNC. 


As it turns out, TCP/IP allows the use of another command to query 
information provided with the finger command. This involves using the telnet 
command (telnet is the command used for keyboard to keyboard communications 
with another TCP/IP station). This gets fairly complicated, but suffice to say that it 
works. Below is another example of using the telnet command to get the same 
information: 


net> telnet n6oyu 79<cr> 


SYN sent 

Established 

[N60YU.norcal.ampr.org] 

$*ka9q<cr> 

Name : PHILIP R. KARN JR 

License: KA9Q License Class: E 

Mail address: 25B HILLCREST RD, WARREN, NJ 07060-0000 
Station address: 25B HILLCREST RD, WARREN, NJ 

Effective date: Sep. 27, 1988 Expiration date: Sep. 27, 
1998 

Previous Callsign: Previous Class: 
Birthdate: Oct. 4, 1956 Process date: Sep. 27, 
1986 


Close wait 
Last ACK 
Closed (Normal) 


In the above example the 79 tells the telnet server to forward the request to the 
finger server, which in this case is the %ka9q on the next line. The server processes 
the request as before. 


Below is a example of an AX25 request: 


Connect N60YU<cr> 
Conn pending 
Connected 
<Carriage Return> 
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[NET-$] 

Welcome to the N6O0YU.norcal.ampr.org TCP/IP Mailbox 
(C)hat (I)nquire (S)end (B)ye > 

I K6LLK<cr> 


Name: JOHN D. CRONIN JR. 

License: K6LLK License Class: E 

Mail address: 1543 FORDHAM CT, MOUNTAIN VIEW, CA 94040- 
0000 

Station address: 1543 FORDHAM CT, MOUNTAIN VIEW, CA 
Effective date: Dec. 9, 1986 Expiration date: Dec. 9, 
1996 

Previous Callsign: Previous Class: 
Birthdate: Jan 1, 1944 Process date: Dec. 9, 
1986 

(C)hat (I)nquire (S)end (B)ye > 

B<etcr> 

Disconnected 


Now all packet user's have access to the Callsign server, via several different 
mechanisms. Since the bringing up of the sever, there have been over 3500 accesses 
over a 6 month period. The service proved especially useful during the last Field 
Day exercises, with several hundred requests during the weekend. An additional 
observation is to see what each new user does with the server. First, almost without 
exception, everyone looks up their own callsign!.... Then they look up their 
friends... 


What is all this running on. Well, the database file is on a 300 Megabyte Hard 
Disk drive which in turn is connected to a Macintosh Plus computer running 
Apple's AppleShare™ fileserver software. The radio is a Yaesu FT-211RH 
connected to an AEA PK-232 TNC and another Macintosh Plus computer running 
the Macintosh version of the KA9Q TCP/IP package. The two computers are 
connected together via LocalTalk™ (Apple's networking system). Additionally a 
Macintosh IIx color system and a LaserWriter IINTX printer also share the network. 


Future Directions 


The future holds many changes for the service. The first will be, of course, a 
more current data file. Next, we plan on changing the method of access. As it 
stands currently, the only was to get callsign information is to directly connect to the 
station via either ax.25 or TCP/IP. What we plan on is similar to the white pages 
lookup now available in the PBBS network. You will be able to send a message to 
the system, with whatever means you have, and the system will send a reply 
message with the callsign information you requested. Now back to the coding... 
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AUSTRALIAN AMATEUR PACKET RADIO ASSOCIATION 


A Brief Report on the Implementation of ROSE Networking. 


Barry E. White, VK2AAB 
28 Redgrave Road 
Normanhurst 
New South Wales 2076 
Australia 


History 


When Net-Rom first became available this association 
obtained the software and installed it in two repeaters, 
VK2RPH in Sydney and VK2RPN in Newcastle 100 miles north of 
Sydney. 


The tests were successful even though we did not reach 
the stage of having a uhf link installed. However we 
received the "WORD" from the Department of Communications 
that the software was in breach of the regulations in that 
the repeaters at one end adopted the callsigns of the users 
and at the other end did not identify both users. We 
therefore had to remove Net-Rom forthwith. I would like to 
take the opportunity to publicly thank Software 2000 for 
their help and consideration to our organisation at that 
time. Their response was beyond what could reasonably 
expected of any organisation. 


Discussions with the Department followed as to what 
their requirements were in regard to packet radio and 
fortuitously I noticed a small item in a bulletin doing the 
rounds of the bbss regarding ’' Rose. Upon further 
investigation and assistance from RATS the Department wrote 
their new regulations for packet in a way that satisfied 
their requirements and enabled Rose to be used. The 
requirement is that each packet shall identify the 
originator, the destination station and the station actually 
transmitting. 


We obtained from RATS an early version of Rose and 
commenced testing and allowing for bugs it was obvious that 
it was able to satisfy our requirements and the Department 
subsequently approved its use. 


The VKNET 


Our initial intention is to expand the installation of 
Rose from Sydney outwards to Brisbane (600 miles) and to 
Melbourne (580 miles). At present we have an installed link 
from Sydney to Orange in the Central West of NSW via 


Kattoomba 80 miles, Mt Bindo a further 30 miles, then to Mt 
Canoblas another 120 miles.The performance of the network 
has been very encouraging especially when the level of 
competing traffic at the Sydney end is considered. 


At present installation of UHF links is underway with 
the Sydney repeater VK2RPH completed and three other 
repeaters almost completed. The hardware being used is 
DR200s and one back to back TNC2 installation. These 
installations have been tested on the bench and should be 
installed by the end of August. 


To achieve our aims nine Rose nodes will be required 
between Sydney and Brisbane and seven between Sydney and 
Melbourne. However these long links will not be very 
satisfactory at our initial installed speed of 1200 baud and 
it is our intention to install at a later time the G3RUH 
9600 baud modems. However UHF linking will not solve our 
major problem of including more remote areas into a nation 
wide VKNET. Discussions have taken place with groups at 
Townsville in Northern Queensland (1500 miles) and Perth 
(2800 miles) regarding the installation of HF Rose nodes 
linked to the local VHF network. Preliminary discussions 
have favoured the 18mhz band and the use of G3RUH 1200 baud 
PSK modems. Arrangements are presently being attempted to 
link the Rose node N2EVW-10 with a Rose node at VK2BBD on 10 
metres. 


Discussions with the Department of Communications will 
have to be undertaken regarding the carrying of packets from 
Limited licensees on the HF network. Initially the Rose 
software is being modified to enable the locking out of 
certain classes of licencees, identified by their callsign 
group, from using the HF network. 


Bandplans 


The Wireless Institute of Australia has established a 
band plan for packet which in addition to the frequencies 
147.575 mhz and 147.600 mhz allocates five frequencies from 
144.800 to 144.900 mhz inclusive. Two extra channels will be 
needed in VK2 at 144.775 and 144.925 mhz. We have allocated 
these channels between the Local Area Networks and each LAN 
will be linked on UHF. 


On HF we are proposing the use of 18mhz for HF 
networking with 1200 baud psk. The success of the HF BBS 
forwarding using PSK has given guidance to the success 
possible with this mode. However some research into the 
propagation difficulties over very long paths at this speed 
is needed. 
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